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ABSTRACT 


The  motivation  for  pursuing  XML-based  tactical  chat  (XTC)  includes  the  great 
potential  of  this  technology  to  fix  limitations  of  current  chat  programs.  XTC  capabilities 
have  the  potential  to  completely  upgrade  and  restructure  all  tactical  military 
communications.  The  current  tools  for  military  chat  include  IRC,  Yahoo,  MSN,  AIM, 
ICQ,  and  NKO.  None  of  these  provides  the  full  functionality  or  interoperability  needed  in 
a  joint  environment.  Moreover,  if  a  nonproprietary  chat  protocol  is  developed,  it  can  lead 
to  a  decision-support  environment  in  which  data,  text,  audio,  and  video  can  be  logged, 
evaluated  and  managed,  all  in  a  Web  environment  where  no  additional  specialized 
software  or  hardware  is  needed. 

Chat  technology  challenges  for  the  military  fit  into  three  areas:  tactical,  technical, 
and  administrative.  Tactically,  there  are  many  ways  chat  can  be  used,  but  effective 
practices  are  not  yet  defined  in  procedures  or  doctrine.  Joint  forces  use  a  myriad  of  chat 
programs  that  don’t  interoperate  and  are  usually  proprietary.  Technically,  many  chat 
programs  are  barred  by  firewalls  and  lack  a  robust  interface  to  allow  logging  and 
searching  past  chats.  From  an  administrative  prospective,  plain-text  chat  has  no  structure. 
Scheduling  and  controlling  who  attends  or  converses  remains  undefined.  Within  DoD 
there  is  no  standard  for  how,  when,  and  by  whom  chats  ought  to  be  conducted. 

Possible  approaches  to  these  problems  include  adopting  a  proprietary  chat  system 
or  customizing  an  open-source  implementation.  Proprietary  solutions  are  costly,  do  not 
interoperate  well,  and  are  too  inflexible  for  a  technology  that  is  evolving  rapidly.  Open- 
source  software  can  provide  a  solution  that  is  adaptable,  extensible,  quick  to  implement, 
straightforward  to  maintain,  and  relatively  inexpensive. 

This  report  provides  a  preliminary  assessment  of  XML-based  tactical  chat  (XTC) 
using  an  open-source,  open-standards  solution.  Promising  initial  results  demonstrate  that 
an  XML  document  can  be  sent  from  a  XHTML  page  in  a  Web  browser  to  an  off-the-shelf 
Jabber  client  via  a  Web  server.  Further,  available  server  and  client  implementations  can 
enable  an  implementation  and  evaluation  plan  for  rapid  development.  Further  work  on 
XTC  is  justified  and  needed. 
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I.  INTRODUCTION 


A.  FOREWARD 

The  majority  of  work  on  this  thesis  was  conducted  between  the  fall  of  2003  and 
the  spring  of  2004.  The  thesis  is  still  written  from  that  perspective  and  provides  some 
interesting  historical  insights  into  where  the  development  of  tactical  chat  came  from.  An 
Afterward  section  was  also  added  to  note  relevant  progress  that  has  occurred  since  the 
original  research  was  completed. 


B.  PROBLEM  STATEMENT 

Text-based  chat  communications  are  used  daily  by  the  military  to  pass 
information,  coordinate  operations,  and  support  collaborative  decision-making.  There  is 
currently  no  standard,  however,  for  application  features,  rules  of  conduct,  or  guidance  on 
monitoring  and  capturing  the  information  that  transpires  in  chats.  A  standardized  chat 
system  has  the  potential  to  handle  large  volumes  of  information  that  can  be  organized  and 
disseminated  for  decision  support. 

Extensible  Markup  Language  (XML)  provides  a  framework  for  standardizing  data 
formats  that  is  applicable  to  a  wide  variety  of  information  types,  including  chat 
communications.  Jabber  is  an  open-source,  extensible  chat  protocol  that  provides  an 
excellent  chat  framework.  This  report  shows  that  Jabber-driven,  XML-based  tactical  chat 
(XTC)  can  provide  an  excellent  environment  for  military  communication,  supporting 
both  current  needs  and  future  decision-support  capabilities.  At  the  same  time,  Jabber- 
based  XTC  avoids  proprietary  client  restrictions  that  limit  effectiveness,  reliability, 
security,  and  interoperability. 

C.  REQUIREMENTS  OVERVIEW 

The  requirements  for  an  effective  tactical  military  chat  system  fall  into  in  three 
major  areas:  tactical,  technical,  and  administrative. 

An  examination  of  tactical  requirements  begins  with  defining  when  and  why  chats 
are  conducted  in  a  military  setting.  As  the  benefits  and  shortcomings  of  current  programs 
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are  reviewed,  future  chat  systems  can  capitalize  on  strengths,  avoid  weaknesses,  and 
identify  potential  features  that  will  take  chat  to  a  new  level  of  benefit.  Chat  is  routinely 
used  for  command  and  control,  operational  planning  and  execution,  and  analysis; 
nevertheless,  none  of  these  is  defined  in  current  communication  doctrine,  nor  do  these 
uses  exploit  the  full  potential  of  chat. 

The  technical  requirements  for  military  chat  arise  from  the  unique  nature  of  the 
communications  environment.  Technical  capabilities  of  interest  include  asynchronous 
protocol,  communicating  across  strict  firewall  settings,  joint  compatibility,  multiple 
message  types,  verifying  code  reliability,  and  designing  adaptable  interfaces.  Many  of 
these  data-interchange  requirements  are  met  by  XML.  Of  particular  importance  is  that  the 
issues  involved  in  exchanging,  organizing,  storing,  and  analyzing  large  volumes  of  chat 
information  can  be  solved  under  XML. 

Administrative  requirements  also  need  to  be  considered,  because  chat  is  a 
relatively  new  coordination  tool  for  military  use.  Lessons  learned  from  large  group 
discussions  can  be  used  to  define  user  roles  and  rules  of  conduct,  i.e.  chat  netiquette,  so 
that  time  spent  in  chat  is  well  used.  Scheduling,  rendezvousing,  monitoring,  and 
controlling  access  are  administrative  requirements  that  will  improve  chat  effectiveness. 
The  relationships  between  decentralized  chat  rooms  exploiting  tactical  opportunity  and 
formal,  chain-of-command  tactical  communications  needs  to  be  better  understood. 
Through  effective  guidelines,  chat  can  become  a  immensely  valuable  tool  for  personnel. 

This  report  provides  a  preliminary  assessment  of  chat  issues  and  opportunities, 
focused  on  tactical,  technical,  and  administrative  requirements.  An  explanation  of  Jabber 
technology  and  how  it  can  be  deployed  is  included,  as  well  as  promising  initial- 
implementation  results.  One  demonstration  shows  that  an  XML  document  can  be  sent 
from  a  XHTML  page  in  a  Web  browser  to  a  chat  room,  using  open-standards,  open- 
source  Jabber  clients  and  Web  servers.  In  addition  it  provides  a  base  server  and  client 
implementation  and  a  strategic  R&D  plan  for  rapid  development  of  XML-based  military 
chat  referred  to  as  XML  Tactical  Chat  (XTC). 
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D.  MOTIVATION 

The  motivation  for  pursuing  XML-based  tactical  chat  (XTC)  is  the  desire  to  offer 
the  power  of  chat  across  the  spectrum  of  tactical  operations.  Such  potential  is  inspired  by 
the  large-scale  growth  of  commercial  chat  clients,  the  XML  capabilities  of  Jabber-based 
chat,  and  the  obvious  potential  of  XML  technology. 

The  U.S.  Joint  Forces  Command  (JFCOM)  is  working  with  the  Space  and  Naval 
Warfare  Systems  Command  (SPA WAR)  and  the  Defense  Collaboration  Tool  Suite  3.0 
engineering  team  to  replace  Envoke  (a  secure  messaging  and  presence  platform 
developed  as  a  research  project  within  DoD)  [Envoke  2004]  with  the  Jabber/XMPP 
(extensible  messaging  and  presence  protocol).  [XMPP  2004]  Dissatisfaction  with  Envoke 
includes  poor  performance  and  reliability,  and  its  proprietary  protocol.  Additionally, 
extending  the  Jabber/XMPP  protocol  to  meet  several  military  needs  is  being  explored, 
including: 

1)  Cross-domain  chat  and  collaboration 

2)  Secure,  low-cost,  high-performance,  reliable,  textual  chat 

3)  Chat  with  translation  (i.e.,  English  to/from  other  languages) 

4)  Scalable  standards-based  replacement  for  T.120,  Envoke,  and  much  of 
Info  Workspace  (IWS)  that  will  reduce  the  procurement  and  deployment  costs  for 
collaboration  tools  for  the  DoD  by  an  order  of  magnitude.  [Boyd  2003] 

Other  tools  presently  used  for  chat  in  the  military  include  Yahoo,  MSN,  AIM, 
ICQ,  and  NKO.  None  provides  the  full  functionality,  security,  or  interoperability  needed 
in  a  joint  environment.  XMPP  can  be  extended  via  XML  namespaces  using  the  Jabber 
enhancement  proposal  process  to  support: 

1)  Whiteboarding 

2)  Audio 

3)  Video 

4)  Translation 

5)  Message  labeling  and  content  signing 
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6)  Application  casting  (1-way  sharing) 

If  adopted  and  approved,  these  capabilities  may  enable  a  decision-support 
environment  that  can  be  logged  and  managed  and  works  in  a  Web  environment  with  no 
other  specialized  software  or  hardware  than  commonly  installed  Web  technology. 

Figure  1  shows  the  XTC  poster  presented  at  the  Interservice/Industry  Training, 
Simulation  and  Education  Conference  (I/ITSEC)  in  2003,  summarizing  the  capabilities 
and  benefits  of  an  XTC  approach.  Figure  2  restates  XTC  must-have  capabilities, 
problems  with  proprietary  applications,  and  standards  benefits  in  text  form. 


XTC  Tactical  Chat  ?  A  X  ® 

Must-Have  Capabilities  http://www.jabber.org  B&UMpwfaAna 


Faster  Response  Times 
Collaboration  Support 
Used  In  OIF  and  Today 
Net-Centric  Warfare 
Single-person  or 
Group  Messaging 


Proprietary:  Bad! 


Can’t  Inspect  Binary  Messages 
Costly  Licenses,  Unpredictable  Support 
Not  Interoperable 

Can’t  Verify  Source  Code  is  Secure 
Not  Allowed  Across  Network  Boundaries 


no:  savage@conference . xchat . Moveslnsti tute . org 


Standards:  Good! 


XML  messaging,  Web  Ready 
Jabber:  Free  Software,  Open  Standards 
Can  Bridge  Multiple  Protocols 
Open  Source:  Inspect,  Modify,  Improve 
Firewall  Friendly,  Many  Applications 


mai 1  to : xmsf-contact@Moves!nsti tute .org 


Figure  1 .  XML-based  tactical  chat  (XTC)  poster  presented  at  I/ITSEC  2003 

summarizes  required  features,  shortfalls  of  commercial  technologies  and  the 
benefits  of  open  standards. 
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Must-Have  Capabilities 

•  Test  Faster  response  times 

•  Collaboration  support 

•  Used  in  Operation  Iraqi  Freedom  (OIF)  and  today 

•  Net-centric  warfare 

•  Single-person  or  group  messaging 
Problems  with  proprietary  solutions 

•  Can’t  inspect  binary  messages 

•  Costly  licenses,  unpredictable  support 

•  Not  interoperable 

•  Can’t  verify  source  code  is  secure 

•  Not  allowed  across  network  boundaries 
Benefits  of  standards-based  solutions 

•  XML  messaging,  Web  ready 

•  Jabber:  Free  software,  open  standards 

•  Can  bridge  multiple  protocols 

•  Open  source:  inspect,  modify,  improve 

•  Firewall  friendly,  many  applications _ 

Figure  2.  XTC  must-have  capabilities,  proprietary  problems,  and  standards  benefits. 

E.  OBJECTIVES 

To  establish  specific  requirements  for  XTC  use  in  military  environments,  this 
report  addresses  the  following  research  questions: 

•  What  benefits  can  XML-based  tactical  chat  provide  to  military  communications? 

•  What  are  the  tactical  requirements  for  XTC? 

•  What  are  the  technical  requirements  for  XTC? 

•  What  are  the  administrative  requirements  for  XTC? 

•  How  can  XML  be  applied  to  chat? 

•  What  is  Jabber  and  how  can  it  be  used  for  tactical  chat? 
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•  What  open-source  Jabber  clients  are  available  and  how  are  they  implemented? 

•  Can  XML  be  sent  from  a  client  to  a  Jabber  server  and  displayed? 

•  Can  chat  information  be  sent  using  a  thin  client  (XHTML  page)  instead  of  thick 
(Jabber  client)? 

•  Can  XML-based  chat  also  be  used  for  software-agent  and  combat-control 
systems  (CCS)  communications? 

•  How  is  a  Jabber  server  configured? 

•  What  are  the  security  benefits  and  concerns  under  Jabber? 

F.  DOCUMENT  ORGANIZATION 

Chapter  I  provides  a  requirements  overview,  motivation,  and  report  objectives  for 
XML-based  Tactical  Chat  (XTC).  Chapter  II  reviews  related  work  in  multicast 
networking,  X3D  graphics,  large-scale  virtual  environments,  and  the  Extensible 
Modeling  and  Simulation  Framework  (XMSF).  Chapter  III  provides  a  list  of  tactical, 
technical,  and  administrative  requirements  needed  for  tactical  chat.  Chapter  IV  is  an 
overview  of  Jabber  technology.  Chapter  V  is  a  Jabber  development  guide,  providing 
details  on  how  to  set  up  a  Jabber  client  and  server,  also  integrating  servlets  and  Java  bean 
capabilities.  Chapter  VI  outlines  the  initial  design,  testing,  and  lessons  learned  for  the 
preliminary  XTC  application  produced  during  this  project.  Chapter  VII  examines  security 
concerns  and  considerations.  Chapter  VIII  summarizes  conclusions  and  gives 
recommendations  for  future  work.  The  appendices  provide  exemplar  XML  schema,  style 
sheets,  server  code,  and  references. 
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II.  RELATED  WORK 


A.  INTRODUCTION 

The  chapter  provides  an  overview  of  diverse  topics  that  provide  information 
relevant  to  XTC.  Topics  covered  include  multicast  backbone  (MBone),  selective 
reliability  multicast,  Extensible  3D  (X3D)  graphics,  and  large-scale  virtual  environments 
(LSVEs).  The  Extensible  Modeling  and  Simulation  Framework  (XMSF),  distributed 
interactive  simulation  (DIS)  protocol,  the  DIS-Java-VRML  (Virtual  Reality  Modeling 
Language)  project,  and  XML  binary  serialization  using  the  Cross-Format  Schema 
Protocol  (XFSP)  are  presented  as  well. 

B.  MULTICAST  BACKBONE  (MBONE) 

Most  multicasting  packets  are  prevented  from  crossing  network  boundaries,  such 
as  routers,  because  of  their  potential  to  saturate  networks.  The  multicast  backbone 
(MBone)  is  a  technology  that  enables  the  distribution  of  live  audio,  video,  and  other 
packets  on  a  global  scale.  MBone  controls  multicast-packet  distribution  by  limiting  their 
lifetime  and  adaptively  restricting  multicast  transmissions  via  sophisticated  pruning 
algorithms,  while  allowing  multicast  packets  to  “tunnel”  through  IP  routers.  [Macedonia, 
Brutzman  1994] 

MBone  is  a  virtual  network  because  it  shares  the  same  physical  media  as  the 
Internet.  It  uses  a  network  of  routers  (mrouters)  that  can  support  multicast.  [Brutzman 
2003]  Of  particular  interest  to  XTC  is  the  ability  to  allow  real-time  video,  audio  and 
whiteboarding  in  a  low-bandwidth  environment.  Unfortunately,  wide-area  multicast  is 
typically  difficult  to  implement  in  practice.  Chat  channels  provide  a  valuable  alternative. 


C.  SELECTIVELY  RELIABLE  MULTICAST 

Selectively  reliable  multicast  uses  the  selectively  reliable  transport  protocol 
(SRTP)  [Pullen  1999]  to  expand  the  transmission-control  protocol’s  (TCP)  unicast 
address  and  port  multiplexing  structure  to  multicast  groups  and  simulation-object  classes 
(sometimes  called  “categories”).  The  initial  implementation  of  SRTP  is  to  support 
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distributed  virtual  simulations  (DVS)  that  are  distributed  over  a  network,  operate  with 
human  participants,  and  require  virtual  representation  in  real  time.  This  requires  that  the 
interconnecting  network  deliver  messages  with  minimal  packet  loss  and  low  latency 
(delay).  [Pullen  1999]  The  traditional  TCP  connection  is  always  point  to  point  and  does 
not  support  multicast. 

Similar  to  the  military  tactical  environment,  “network-based  distributed 
simulation  characteristically  generates  large  amounts  of  message  traffic  among  the 
computers  supporting  elements  of  the  simulation.  In  the  general  case  this  requires  many- 
to-many  communications  among  a  group  of  computers  conducting  some  aspect  of  the 
simulation.”  [Pullen  1999]  There  is  potential  to  apply  SRTP  to  XTC  in  order  to  harness 
its  benefits  of  minimal  delay  in  a  high-traffic  environment. 

D.  EXTENSIBLE  3D  (X3D)  GRAPHICS 

The  X3D  specification  uses  XML  to  encode  3D  scenes;  specifically,  a  diverse  set 
of  model  geometries  and  behaviors  expressed  in  the  VRML  97  encoding.  Because  X3D  is 
coded  as  XML,  XTC  clients  might  use  the  X3D  format  to  pass  virtual-reality  models 
among  participants.  Jabber  chat  capabilities  might  also  be  integrated  into  X3D  script 
nodes  as  a  streaming  mechanism  for  animation  data,  thus  providing  a  many  to  many 
channel  for  participants  in  virtual  environments.  These  are  important  areas  for  future 
work. 

Figure  3  contains  the  abstract  from  Web-Based  3D  Graphics  Rendering  of 
Dynamic  Deformation  Structures  in  Large-Scale  Distributed  Simulations  [Brutzman 
2003]  as  a  detailed  reference  showing  the  value  of  real-time  web-based  3D  graphics. 
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This  report  examines  multiple  technologies,  constraints  and  strategies  for  Web- 
based  3D  rendering  of  dynamic  defonnation  structures  in  military  simulations.  The 
motivating  goal  is  to  show  how  all  manner  of  3D  objects  can  be  modeled,  animated  and 
manipulated,  in  a  scalable  and  repeatable  fashion,  in  support  of  distributed  large-scale 
virtual  environments  (LSVEs).  Such  capabilities  have  broad  training,  analysis  and 
operational  value. 

Web-based  3D  graphics  are  the  critical  technology  needed  for  rendering  the 
dynamic  deformation  of  structures  in  distributed  military  simulations.  This  is  a  broad 
subject  area  with  many  specific  requirements.  The  Extensible  3D  (X3D)  Graphics 
standard  undergoing  ISO  review  includes  nearly  the  full  range  of  capabilities  needed. 

This  approach  differs  from  other  technical  possibilities  through  adherence  to  an  open 
standard,  royalty-free  licensing  for  any  use,  availability  of  both  commercial  and  open- 
source  implementations,  provision  for  alternate  software  application  programming 
interfaces  (APIs),  multiple  extensibility  mechanisms,  and  a  growing  content  base  of 
compatible  3D  models. 

Of  particular  importance  is  that  X3D  supports  encoding  of  scenes  using  the 
Extensible  Markup  Language  (XML),  which  ensures  that  files  are  self-validating  and 
capable  of  reliable  processing.  Since  XML  is  well  suited  to  both  Web  interchange  and 
database  interoperability,  X3D  using  XML  encodings  provides  new  capabilities  for  large- 
scale  production. 

Advanced  X3D  capabilities  include  geospatial  referencing,  humanoid  animation, 
shared-state  distribution  using  the  IEEE  Distributed  Interactive  Simulation  (DIS) 
protocol,  building  prototypes,  server-produced  custom  terrain,  image  overlay  of 
photographic,  cartographic  or  pseudocolor  images,  integrated  physics  for  entity  motion 
and  sensor  projection,  a  variety  of  user-interaction  techniques,  and  scalable 
loading/unloading  of  interrelated  scenes. 

The  multiple  challenges  involved  in  modeling  deformable  surfaces  cannot  each  be 
solved  in  isolation.  3D  graphics,  underlying  model  representations  and  networked 
distribution  at  first  appear  to  be  different  topics.  Nevertheless,  solutions  for  each  area 
must  simultaneously  consider  constraints  and  capabilities  of  other  areas.  Compatible 
integration  within  a  Web-based  framework  allows  effective  use  of  deformable  surfaces 
for  diverse  military  simulations.  This  report  presents  results  emphasizing  standards-based 
interoperability,  scalable  architectures,  demonstrated  examples  and  directions  for  future 
work. 

Figure  3.  Abstract  from  Web-Based  3D  Graphics  Rendering  of  Dynamic 

Deformation  Structures  in  Large-Scale  Distributed  Simulations  provides  a 
detailed  reference  showing  the  value  of  real-time  web-based  3D  graphics.  [From 
Brutzman  2003] 
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E.  LARGE-SCALE  VIRTUAL  ENVIRONMENTS  (LSVES) 

Large-scale  virtual  environments  (LSVEs)  can  link  hundreds  of  people  and 
artificial  agents  with  interactive  3D  graphics,  massive  terrain  databases,  global 
hypennedia  and  scientific  datasets.  To  do  this,  four  key  communication  methods  are 
used:  lightweight  messages,  network  pointers,  heavyweight  objects  and  real-time  streams. 
For  each  of  these  four  methods,  bandwidth  and  latency  must  be  carefully  considered. 
[Brutzman  2004] 

Large-scale  virtual  environments  and  XTC  face  similar  challenges  and  solutions 
to  widely  distributed  real-time  streaming.  Specifically: 

•  Multicast  protocols  permitting  moderately  large  real-time  bandwidths  to  be 
efficiently  shared  by  an  unconstrained  number  of  hosts. 

•  MBone  connectivity  permitting  live  distribution  of  graphics,  video,  audio,  DIS 
and  other  streams  worldwide  in  real  time.  [Brutzman  2004] 

The  article  "Exploiting  Reality  with  Multicast  Groups"  [Macedonia  1995] 
describes  groundbreaking  research  on  increasing  the  number  of  active  entities  within  a 
virtual  environment  by  several  orders  of  magnitude.  Multicast  addressing  and  the  DIS 
protocol  are  used  to  logically  partition  network  traffic  according  to  spatial,  temporal,  and 
functional-entity  classes.  "Exploiting  Reality"  further  explains  virtual  environment 
network  concepts  and  includes  experimental  results.  This  work  has  fundamentally 
changed  the  distributed-simulation  community,  showing  that  very  large  numbers  of  live 
and  simulated  networked  players  in  real-world  exercises  are  feasible.  The  military  origins 
of  this  problem  will  become  irrelevant  as  our  abilities  to  effectively  interact  socially, 
scientifically,  and  educationally  scale  to  the  hundreds  of  thousands.  [Brutzman  2004] 

In  practice,  widespread  multicasting  for  LSVEs  has  been  difficult  to  achieve  due 
to  administrative,  routing  and  social  barriers.  The  Jabber  protocols  hold  great  promise  as 
a  potential  mechanism  to  achieve  these  long-sought  breakthroughs.  Considering  and 
addressing  these  historic  technical  challenges  is  important  if  XTC  is  to  scale  as  broadly  as 
needed. 
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F.  EXTENSIBLE  MODELING  AND  SIMULATION  FRAMEWORK  (XMSF) 

The  Extensible  Modeling  and  Simulation  Framework  (XMSF)  can  be  found  at 
http://www.movesinstitute.org/xmsf/xmsf.html.  XMSF  is  defined  in  Figure  4: 


A  set  of  Web-based  technologies,  applied  within  an  extensible  framework,  that 
enables  a  new  generation  of  modeling  and  simulation  applications  to  emerge,  develop, 
and  interoperate.  Specific  subject  areas  for  XMSF  include  Web/XMF, 
intemet/networking,  and  modeling  and  simulation  (M&S).  The  precepts  of  XMSF  are: 

•  Web-based  technologies  applied  within  an  extensible  framework  will  enable  a 
new  generation  of  M&S  applications  to  emerge,  develop  and  interoperate 

•  An  extensible  framework  of  XML-based  languages  can  provide  a  bridge 
between  forthcoming  M&S  requirements  and  open/commercial  Web  standards,  while 
continuing  to  support  existing  M&S  technologies 

•  Compatible  and  complementary  technical  approaches  are  now  possible  for 
model  definition,  simulation  execution,  network-based  education,  network  scalability, 
and  2D/3D  graphics  views. 

•  Web  approaches  for  technology,  software  tools,  content  production  and  broad 
use  provide  best  business  cases  from  an  enterprise-wide  (i.e.  worldwide)  perspective. 
Figure  4.  Extensible  Modeling  Simulation  Framework  (XMSF)  defined.  [From 

Brutzman,  et  al.  2003] 

The  goal  of  XTC  is  to  fit  XML-based  chat  within  the  capabilities  of  XMSF. 
Multiple  demonstration  examples  are  now  underway  to  test  capabilities  and  achieve 
diverse  cross-language  interoperability  via  chat  transport  of  web  services. 


G.  DISTRIBUTED  INTERACTIVE  SIMULATION  (DIS)  PROTOCOL 

DIS- JA V A- VRML  PROJECT 

The  IEEE  Distributed  Interactive  Simulation  (DIS)  Protocol  is  used  to  create  a 
common,  interactive,  virtual  interface  within  a  multi-system  network  by  communicating 
distributed  simulation  state  information.  DIS  provides  the  common  interfaces, 
architectures  and  structures  required  to  support  this  integrated  environment.  The  goals  of 
the  DIS-Java-VRML  project  (http://www.web3d.org/WorkingGroups/vrtp/dis-iava-vrml) 
are  as  follows: 

•  Complete  a  freely  available  reference  Java  implementation  of  the  DIS 
protocol 


11 


•  Produce  a  set  of  recommended  practices  for  mapping  between  DIS  and 
VRML  worlds 

•  Develop  assorted  DIS  utilities:  record/playback,  DIS  viewers,  etc. 

•  Develop  math  libraries  and  physics  libraries 

The  DIS- Java- VRML  project  provides  a  valuable  resource  for  testing  example 
application  interactions  between  XTC  and  DIS.  Current  research  work  is  examining  the 
potential  of  DIS  as  XML  and  Web  Services. 


H.  COMMAND  AND  CONTROL  INFORMATION  EXCHANGE  DATA 

MODEL  (C2IEDM) 

The  C2IEDM  is  a  NATO  initiative  to  standardize  the  information  exchange 
between  coalition  partners  by  creating  a  standard  data  structure.  The  C2IEDM  is  based  on 
the  Battlespace  Generic  Hub  (BGH)  concept  which  applies  broad  categories  to  military 
activities  within  the  battlespace.  [Neushul  2003]  XTC  can  use  the  BGH  as  a  guide  to 
define  the  XML  tags  so  that  it  can  interface  with  coalition  systems.  Successfully 
implementing  C21EDM  capabilities  in  XTC  applications  is  expected  to  provide 
internationalized  coalition-capable  tactical  communications  with  consistent  context  and 
semantics. 


I.  XML  SCHEMA-BASED  BINARY  COMPRESSION  (XSBC) 

XSBC  is  of  particular  interest  to  XTC  because  of  its  ability  to  compress  message 
streams  and  its  potential  for  higher  performance  in  a  low  or  noisy  bandwidth 
environment.  XSBC  is  described  as  follows: 

XSBC  has  been  developed  as  a  general  approach  to  binary 
serialization  of  XML  documents.  Elements  and  attributes  are  replaced  via 
a  tokenization  scheme  which  carefully  preserves  valid  XML  document 
structure.  XSBC  uses  XML  schema  as  the  basis  for  determining  key 
document  parameters  such  as  legal  elements,  attributes  and  data  types. 

Originally  motivated  by  the  flexible  definition  of  networking  protocols, 
binary  serialization  of  XML  via  XSBC  appears  suitable  both  for  message 
streams  and  document-storage  streams. 
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An  open-source  XSBC  software  implementation  written  in  Java 
demonstrates  the  viability  of  the  XSBC  approach  for  XML  document 
serialization  and  deserialization.  Compression  measurements  using  Virtual 
Reality  Modeling  Language  (VRML  97)  scenes  have  shown  expected 
compression  results: 

•  XML  encoding  of  non-XML  data  (e.g.  translation  of  VRML  .wrl 
scenes  into  .x3d  documents)  typically  increases  file  size. 

•  XML-aware  compression  of  XML  encoded  data  (in  this  case  via 
XSBC)  provides  superior  compression  to  gzip  compression  of  the  original 
data.  This  occurs  because  the  regularity  of  document  structure  is  more 
exploitable  than  alphanumeric  patterns. 

•  Deserialization  of  compressed  XML  as  in-memory  data 
structures  provides  higher  performance  since  a  second  parse  of  string- 
based  data  is  not  required.  [Brutzman,  McGregor  2003] 


Application-related  communications  will  be  performed  as  web-service  requests. 
Binary  XML  compression  of  messages  and  data  streams  show  greater  compression 
performance  than  is  possible  with  gzip,  and  faster  decompression  parsing,  while  retaining 
self-check  schema-validation  capabilities  of  XML.  NPS  further  expects  to  allow  optional 
addition  of  Hamming-code  forward  error  correction  (FEC)  to  all  binary  XML  messaging, 
allowing  receiver-side  error  detection  and  correction  without  retransmission.  When 
combined  with  improved  XML  interoperability,  such  capabilities  can  be  considered 
superior  to  the  majority  of  existing  machine -to-machine  tactical  communication 
encodings  used  by  fleet  systems. 


J.  SUMMARY 

This  chapter  describes  a  wide  range  of  topics  that  are  relevant  to  XML-based 
tactical  chat.  Topics  covered  include  multicast  backbone  (MBone),  selective  reliability 
multicast,  X3D  graphics,  large-scale  virtual  environments,  XMSF,  the  DIS  protocol  and 
DIS- Java- VRML  project,  and  XSBC  compression  for  XML-based  messaging. 
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III.  CURRENT  CHAT  INITIATIVES 


A.  INTRODUCTION 

This  chapter  presents  an  overview  of  the  use  of  chat  in  the  Navy  circa  2004.  It 
discuses  the  findings  at  the  IRC  users  conference,  categorizes  the  major  efforts  being 
undertaken  to  improve  the  navy’s  chat  capabilities,  and  outlines  some  of  the  shortfalls  of 
current  chat  tools.  Lastly  it  discusses  the  top  priorities  from  a  recent  IRC  users 
conference. 

B.  STATUS  OF  CHAT 

At  the  IRC  users  conference  held  at  SPAWAR  systems  center  22-23  June  2004 
[SPAWAR  2005]  the  current  uses  of  chat  in  DOD  were  discussed  and  the  requirements 
for  the  next-generation  chat  client  were  identified  as  follows: 

•  Low  bandwidth 

•  Multiple  Chat  windows 

•  Standing  Chat  rooms 

•  Public  rooms  (password  protected) 

•  Support  both  Unix  and  Windows  operating  systems 

•  Time  Stamp  and  log  (required  by  law) 

•  Auto  reconnect  to  rooms  upon  regaining  connectivity 

•  Auto  download  of  missing  recent  message  logs  upon  joining 

•  Streamlined  log-in  process  (Large  log-in  app  is  problematic) 

To  clarify  what  was  considered  high,  medium  and  low  bandwidth  the  following 
ranges  were  defined: 

•  Low  Bandwidth  (10-64  Kbps)  Cell  phone 

•  Medium  Bandwidth  (64-128  Kbps) 
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High  Bandwidth  (128  Kbps) 


The  discussion  centered  around  what  chat  tools  were  currently  being  used  and 
where  efforts  needed  to  be  focused  to  improve  current  chat  capabilities. 


C.  FORCENET 

FORCEnet  is  the  Navy’s  attempt  to  improve  Command  and  Control  (C2)  by 
leveraging  the  power  of  modern  communications  technology.  Navy  Networks  Warfare 
Command  (NNWC)  is  charged  with  implementing  FORCEnet  and  their  primary 
mechanism  to  evaluate  progress  is  an  annual  experiment  call  Trident  Warrior. 


D.  TRIDENT  WARRIOR  04 

The  Trident  Warrior  experiment  is  NNWC’s  annual  experiment  that  measures  the 
ability  of  current  and  new  technologies  to  implement  FORCEnet  in  the  fleet.  In  Trident 
Warrior  04  (TW04)  the  effectiveness  of  two  chat  technologies  was  measured:  Distributed 
IRC  chat  and  Shore -based  web-client  chat.  The  Distributed  IRC  chat  server  architecture 
was  tested  by  the  Center  for  Naval  Analysis  (CNA)  and  was  successful  in  increasing 
uptime  for  chat  users.  The  Shore-based  web-client  was  developed  and  hosted  at 
FNMOC.  The  client  used  a  Jabber  based  server  and  a  servlet  interface,  however  they  did 
not  finish  development  of  the  product  and  it  was  not  successfully  tested  in  TW04. 


E.  CHAT  CLIENTS 

The  following  is  a  list  of  current  chat  clients  being  worked  on. 

1.  IRC 

IRC  chat  is  the  current  tool  of  choice  in  the  Navy.  It  has  some  inherit 
characteristics  that  make  it  easy  to  use  and  very  practical  for  a  low  bandwidth 
environment.  However  there  are  same  major  issues  with  it  including  licensing  and  the 
inability  to  authenticate  users. 

The  common  chat  clients  for  IRC  are  Microsoft  chat  (MSchat),  mIRC  and  Zircon. 
Each  of  these  clients  has  both  administrative  issues  and  functional  shortfalls.  MSchat  is 
part  of  the  government  off  the  shelf  -  Delta  (GOTS-D)  software  load  but  it  is  no  longer 
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supported  by  Microsoft.  mIRC  is  a  shareware  program  written  by  Khaled  Mardam-Bey  a 
Jordanian  national  who  requires  payment  of  $20  a  copy  after  the  30-day  trial  period. 
Although  this  program  is  used  prolifically  across  the  SIPRnet,  no  payment  has  been  made 
at  this  time.  Zircon  is  an  X-windows  client  that  is  loaded  on  GCCS-M  servers  and 
clients,  but  does  not  have  a  windows  version. 

Some  of  the  good  features  of  IRC  are:  low  bandwidth,  allows  multiple  chat 
windows,  has  standing  chat  rooms,  has  public  rooms  (password  protected),  support  Unix 
and  Windows,  has  time  stamping  and  logging,  can  auto-reconnect  to  rooms,  and  handles 
disconnects.  The  bad  features  are:  Separate  client  is  needed  to  maintain  chat  room  and 
record  logs,  licenses  for  current  clients  not  paid,  no  support  for  MSchat,  and  no 
authentication. 

2.  NKO  Chat  (banyan  vines) 

The  good  thing  about  NKO  chat  is  that  it  is  integrated  into  the  NKO  portal. 
Unfortunately  the  following  features  make  it  unusable  afloat:  Single  administrator-  not 
transferable,  very  slow  (applet),  and  high  bandwidth. 

3.  Lotus  Sametime 

Like  NKO  the  good  thing  about  Sametime  is  that  it  is  already  integrated  into 
Collaboration  At  Sea  (CAS),  a  deployed  system,  however  it  also  requires  an  applet  to 
log-in  and  is  high  bandwidth. 

4.  WebE 

Is  the  tool  used  by  the  Special  Forces.  It  is  IRC  compatible,  has  a  high  degree  of 
functionality,  can  send  fdes  including  voice  using  a  drag  and  drop  feature,  and  each 
server  supports  5000  users,  unlimited  #  of  servers.  However  it  has  a  protocol  that  is 
proprietary,  uses  port  443  and  80,  and  cost  $5000  a  server,  $22  a  client. 

5.  Netmeeting 

Netmeeting  provides  file  sharing  capabilities,  however  it  is  invite  only,  high 
bandwidth,  and  has  security  vulnerabilities. 

6.  Defense  Collaboration  Tool  Suite  (DCTS) 

Defense  Collaboration  Tool  Suite  (DCTS)  is  a  set  of  collaborative  tools  approved 
for  use  across  the  Department  of  Defense  (DOD).  DCTS  currently  includes  Microsoft 
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Netmeeting,  Sun  Forum,  Envoke  Instant  Messaging,  Digital  Dashboard,  and  CUSeeMe. 

A  number  of  other  products,  such  as  Lotus  Sametime  and  Groove,  are  undergoing  testing 
to  gain  DCTS  approval. 

•  DCTS  has  LDAP 

•  DCTS  available  to  coalition 

•  DCTS  can  not  participate/monitor  in  IRC  group  chat  rooms. 

•  Can  not  be  in  Open  multiple  chats  in  portal/client 

7.  Envoke 

Envoke  (Asynchronous  Solutions  for  DISA)  part  of  DCTS  main  purpose  is 
“global  awareness”  uses  APIs  and  third  party  collaboration  tools.  It  has  standalone  client 
and  portal  environment.  It  has  interoperability  with  Groove  and  WebE.  A  server  called 
Bridgette  lives  between  envoke  and  IRC  and  or  XMPP,  server  is  flexible  enough  to  reside 
on  Envoke,  IRC,  or  separate  server,  Conops/ Architecture  not  decided  yet.  Bridgette 
inherits  the  IRC  problem  of  non-authentication. 

8.  Jabber 

Jabber  is  currently  being  worked  on  for  the  Joint  Expeditionary  Forces 
Experiment  (JEFX).  They  are  modifying  the  open  source  client  Rhymbox.  FNMOC  is 
also  working  on  the  web  based  chat.  Good  things  with  Jabber  are: 

•  Replicate  chat  room  in  2  servers  across  firewall 

•  Send  image  (or  other  files) 

•  Presence 

•  Security  (supports  SSL) 

•  Open  standards  based 

•  Can  supports  XForms  as  embedded  payload 

•  Simple  server,  complex  servers 

•  Supports  web-based  client  and  thick  client 

•  Distributed 
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Another  presenter  at  the  conference  was  Jabber  Inc.  who  added  some  great  insight 
into  the  power  of  Jabber. 

•  Great  features  including  blackberry  handheld  connectivity  and  cell  phone 
interoperability. 

•  Cost:  max  $30  a  user,  approximately  70%  lower  for  a  large  number  of 
users. 

•  Government  clients  include  the  CIA,  Intelink,  JFCOM,  and  the  U.S.  Army 
Future  Combat  Systems.  [Jabber  2005] 

•  Preliminary  tests  show  27  Kbps  used  for  2000  users. 


F.  TOP  RECOMMENDATIONS  FOR  CHAT 

From  the  IRC  users  conference  there  were  6  major  issues  that  were  identified  as 
high  priority. 

1.  Choose  a  Server  /  Client  /  Database  Architecture 

At  some  point  in  the  near  future  the  technologies  that  are  going  to  be  used  will 
need  to  be  agreed  upon  and  a  common  server,  client  and  database  standard  needs  to  be 
implemented. 

2.  Define  Security  Requirements 

Currently  the  security  requirements  for  chat  are  not  defined.  There  is  no  way  to 
develop  a  chat  client  that  meets  security  standards  if  those  standards  are  not  defined.  The 
standard  needs  to  include  what  is  required  for  security  accreditation  of  a  new  protocol 
across  Navy  firewalls. 

3.  Distributed  Server  Architecture  w/  Chat  Rooms  and  Contacts 

Whatever  technology  is  decided  on  needs  to  at  a  minimum  support  a  distributed 
chat  architecture  and  chat  rooms  with  user  contact  information. 

4.  Gathering  User  Requirements 

This  paper  attempts  to  gather  all  the  requirements  for  chat  in  one  place  but  a 
formal  requirements  gathering  process  needs  to  be  implemented. 
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5.  TTPs  for  Using  Chat  and  Administration/Logging 

There  are  no  current  standard  Tactics,  Techniques  and  Procedures  (TTPs)  for 
using  or  administering  chat  in  the  Navy.  These  TTPs  need  to  be  developed  by 
NETWARCOM  and  distributed  to  the  fleet. 

6.  Develop  an  Intermediate  IRC  Chat  Client 

The  future  of  Navy  chat  is  not  IRC  however  until  the  next  generation  chat  client  is 
available  the  current  capability  needs  to  be  maintained  and  licensing  and  current 
shortfalls  need  to  be  addressed 

G.  SUMMARY 

The  chapter  discusses  current  chat  initiatives,  the  finding  of  the  2003  IRC  users 
conference,  and  the  road  ahead. 
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IV.  TACTICAL,  TECHNICAL,  ADMINISTRATIVE  AND 
SECURITY  REQUIREMENTS  FOR  XTC 

A.  INTRODUCTION 

This  chapter  describes  the  tactical,  technical,  administrative  and  security 
requirements  of  chat  for  the  military  environment.  Tactical  requirements  define  when  and 
why  chats  are  being  conducted  in  a  military  environment,  as  well  as  the  potential  for 
increased  benefits  of  chat.  Technical  requirements  include  enhancements  that  may  be 
gained  by  leveraging  the  structure  and  flexibility  of  messaging  and  XML,  as  well  as 
solutions  to  specific  technical  hurdles  for  military  chat  applications.  Administrative 
requirements  refer  to  rules  concerning  chat  conduct,  and  implementation  at  the  user  level 
that  enable  chat  to  proceed  effectively.  Security  requirements  details  the  concerns  and 
issues  involving  general  information  security,  code  reliability  and  information  assurance 
(IA)  policies. 


B.  GOAL  OUTCOMES 

The  goal  in  defining  tactical,  technical,  and  administrative  requirements  is  to 
better  understand  the  uses  of  chat  in  a  military  environment  so  that  end-user  applications 
can  flexibly  support  its  many  potential  uses.  Chat  is  already  changing  the  way  operations 
are  conducted  in  the  military,  and  better  defining  chat’s  requirements  may  improve  (or 
indeed  revolutionize)  all  tactical  communications.  A  chat  system  can  incorporate  various 
human  communications  such  as  e-mail  and  message  traffic,  integrating  these  with  system 
information  to  potentially  reduce  user  information  overload.  The  same  chat  system  can 
handle  system-to-system  communications,  greatly  reducing  the  complexity  of  modern 
networking. 

C.  TACTICAL  REQUIREMENTS 

1.  Overview 

Recent  doctrinal  emphasis  on  network-centric  warfare  has  led  to  unprecedented 
connectivity  among  operational  forces.  As  a  result,  significant  command-and-control 
functionality  previously  dependent  on  voice  and  message  circuits  has  shifted  to 
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nontraditional  resources  such  as  e-mail,  instant  messaging,  and  chat.  Chat  in  particular 
has  become  the  tool  of  choice  for  real-time  coordination  and  planning  among  distributed 
operational  forces.  In  fact,  operational  units  at  all  levels  of  command,  from  component 
and  task-force  commanders  to  individual  ships,  have  assigned  watchstanders  to  monitor 
relevant  tactical  chat  rooms  [Houlihan  2003].  At  present,  operational  chat  utilization  can 
be  divided  into  three  fairly  broad  categories:  command  and  control,  operational  planning 
and  execution,  and  administrative  coordination.  An  additional  advantage  to  the  use  of 
chat  by  operational  forces  is  the  ability  to  automatically  maintain  chat-room  logs  and 
archives,  which  provides  a  valuable  resource  to  analysts  responsible  for  after-action 
operational  “lessons  learned”  and  measures  of  effectiveness.  Proper  setup  and  support 
will  further  facilitate  tactical  reconstruction. 

2.  Command  and  Control 

Reliable  digital  connectivity  between  watchstanders  deployed  in  dispersed 
military  units  enables  operational  commanders  to  maintain  real-time  contact  with 
subordinate  units,  regardless  of  physical  location.  Tactical  chat  provides  an  interactive, 
real-time  means  of  passing  information  to  all  levels  of  the  chain  of  command 
simultaneously.  In  particular,  recent  operations  have  shown  that  situation  reports, 
execution  checklist  milestones,  and  casualty  reports,  as  well  as  other  draft  reports,  are 
now  often  passed  via  chat.  This  occurs  with  a  level  of  detail  not  practical  in  voice  circuit 
communications,  and  timeliness  not  available  in  record-message  traffic.  Additionally, 
instantaneous  feedback  available  to  all  chat  participants  decreases  potential  confusion  and 
miscommunication,  facilitating  dissemination  of  amplifying  and  clarifying  information. 

The  following  excerpt  from  a  recent  article  provides  a  good  example  of  chat  being 
used  for  real-time  tactical  coordination  in  Operation  Iraqi  Freedom  as  described  by 
RADM  Paul  F.  Sullivan,  USN: 

“They  [the  sub  crews]  were  sitting  there  with  four  different  chat  rooms,  real-time, 
all  interconnected  24/7  with  Command  Authority  [and  with  other  subs].  When  one  sub 
had  a  firing  problem,  another  helped  with  troubleshooting  and  getting  the  missile  ready  to 
launch”  [Sullivan  2003]. 
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3.  Operational  Planning  and  Execution 

One  of  the  greatest  operational  benefits  of  chat  is  its  applicability  to  operational 
planning  and  execution.  Chat  has  quickly  become  a  principal  means  of  communicating 
intentions  and  requirements  between  dispersed  units  collaborating  in  operational  or 
training  events.  The  ability  to  bring  all  participants  together  for  planning  on  short  notice 
with  no  logistical  or  operational  overhead,  and  to  provide  interoperability  among 
dissimilar  units,  facilitates  the  flexibility  to  adapt  plans  “on  the  fly”  in  a  dynamic 
environment.  Event  scheduling  and  coordination,  deliberate  planning  of  all  aspects  of 
future  events  (including  requests  for  information,  phased  campaign  milestones, 
supported/supporting  unit  coordination,  strike  planning,  troop  movements,  logistics,  and 
peer-to-peer  planning  of  specifics),  and  real-time  planning  in  response  to  short-fused 
operational  exigencies  such  as  the  need  for  search  and  rescue  and  personnel  recovery, 
weather  degradation,  and  materiel  casualties,  have  all  benefited  from  the  real-time 
connectivity  provided  by  chat.  Further,  this  planning  capability  applies  to  and  has  proven 
equally  valuable  at  many  levels  of  command,  from  component  commanders  planning 
macro  aspects  of  major  campaigns  to  individual  units  planning  discrete  evolutions. 
During  the  Seventh  Fleet’s  fleet-battle  experiment  “Kilo,”  chat  was  used  extensively  to 
pass  infonnation  and  coordinate  among  coalition  forces.  [Schacher  2003] 

4.  Coordination 

Perhaps  superficially  less  compelling,  but  no  less  important  to  operational 
success,  is  the  employment  of  chat  to  facilitate  administrative  and  logistical  coordination 
among  units.  Connectivity  between  parent  and  detached  units,  superior  and  subordinate 
units,  and  supporting  and  supported  units  has  proven  an  invaluable  resource  for 
coordinating  administrative  support,  logistics,  technical  support,  and  a  plethora  of  other 
mundane  requirements.  While  voice  circuits  and  message  traffic  provide  only 
cumbersome,  often  unreliable  means  of  coordinating  needs,  chat  provides  robust  person- 
to-person  real-time  connectivity  that  has  been  proven  to  provide  inestimable  support  time 
and  time  again. 

A  good  example  of  the  warfighting  advantages  of  chat  utilization  is  the  NUWC 
chat  implementation  for  managing  Tomahawk  land-attack  missile  (TEAM)  capability 
among  deployed  submarine  forces.  By  monitoring  various  tactical  reports,  TEAM 
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inventory  reports,  and  casualty  reports,  and  providing  technical  guidance  and  advice  to 
deployed  units,  NUWC  was  able  to  support  both  firing  units  and  TLAM  strike 
coordinators  to  ensure  that  submarine  forces  supporting  contingency  operations  in  Iraq 
were  operationally  effective.  [McCormack  2003]  This  article  is  attached  with  permission 
from  NUWC  as  Appendix  D. 

5.  Operational  Analysis 

Logging  of  chat-room  traffic  provides  an  excellent  resource  for  reconstruction  and 
analysis  of  operational  events.  Of  particular  interest,  chat  logs  provide  insight  into 
decision-making  processes  unavailable  by  other  means.  Two  shortcomings  of  the 
operational  use  of  traditional  chat  in  this  regard  are  the  use  of  unlogged  private  chat 
rooms  (wherein  decision  makers  discuss  a  situation  before  promulgating  decisions  in  the 
logged  room)  and  the  inherent  difficulty  of  gleaning  relevant  information  from  reams  of 
freeform  conversation.  While  overuse  of  private  “whisper  chat”  rooms  remains  a 
possibility  (but  one  that  can  be  dealt  with),  the  highly  structured  nature  of  schema- 
governed  XML  is  able  to  finally  regularize  the  data  mining  of  chat  logs  for  a  variety  of 
reconstruction  purposes.  Chat  logging  is  not  well  supported  and  needs  to  be  improved. 
Chat  logging  is  primarily  needed  on  servers.  Augmenting  server  logs  with  additional  logs 
on  individual  clients  may  further  facilitate  after-action  correlation  and  analysis.  This  will 
be  especially  helpful  in  determining  overall  system  reliability  and  distributed  actions 
during  periods  of  intennittent  connectivity. 

6.  Shortcomings  of  Current  Chat  Systems 

While  present  commercial  chat  functionality  is  sufficient  to  have  raised  its  status 
to  become  a  valued  operational  tool,  its  freefonn  nature  and  proprietary  software 
constraints  introduce  two  significant  limitations.  While  it  has  been  noted  that  the 
freeform  discourse  of  chat  systems  makes  data  analysis  difficult,  this  is  in  fact  simply  one 
manifestation  of  a  larger  shortcoming.  Because  of  the  problems  in  parsing  free-form  chat 
text,  it  is  difficult  to  provide  for  automated  data  collection,  collation,  and  usage  in  new 
capabilities  such  as  tactical  updates,  post-mission  operational  analysis,  and  watch 
turnover.  Commercial  software  executables  provide  zero  confidence  that  infonnation 
assurance  (IA)  requirements  are  met — and  surreptitious  eavesdropping  or  relaying  of 
tactical  messages  is  intolerable.  Further,  proprietary  systems  make  the  problem  of 
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application  maintenance  and  adaptation  to  military  requirements  all  but  intractable.  The 
bottom  line  is  that  proprietary  protocols  and  applications  benefit  the  vendor  far  more  than 
the  military  end  user.  A  customized  XTC  client  is  needed  to  capitalize  on  the  many 
potential  benefits  of  chat. 

7.  Recommended  Tactical  Requirements 

Figure  5  presents  the  recommended  tactical  requirements  for  chat. 

1.  Support  command  and  control  to  include  ongoing  dialog  as  well  as  situation 
reports,  execution  checklist  milestones,  and  casualty  reports 

2.  Support  operational  planning  at  the  micro  and  macro  levels  for  both  upcoming 
and  real-time  event  scheduling  and  coordination 

3.  Support  coordination  efforts  for  administrative  support,  logistics,  technical 
support,  and  other  day-to-day  requirements 

4.  Log  all  chats  so  that  valuable  information  is  preserved  for  search  and  ready 
analysis 

5.  XML-ize  chat  to  reduce  the  effort  required  to  extract  infonnation 

6.  Use  an  open-source  solution  that  provides  information  assurance  and  is 
extensible  for  future  requirements. 

Figure  5.  Recommended  tactical  requirements  for  XML-based  tactical  chat. 

D.  TECHNICAL  REQUIREMENTS 

1.  Overview 

The  technical  requirements  for  tactical  chat  comprise  two  major  concerns:  data 
formats  and  application  design.  Data  format  issues  include  XML  markup,  XSLT,  BGH 
compatibility,  MIME  types,  URLs,  and  enhanced  data-mining  functionality.  Application- 
design  concerns  include  asynchronous  data  exchange,  thin-client  configuration, 
interoperability,  firewall-policy  compatibility,  and  open-source  software  design. 

2.  XML  Markup 

XML  is  a  standard  for  marking  up  data,  used  to  create  a  language  that  describes 
that  data  [Hunter  2001].  XML  describes  many  types  of  data,  as  seen  in  the  related  work 
chapter,  and  can  be  applied  to  describe  chat  data.  By  describing  this  data  with  XML,  a 
user  can  provide  forms  for  submitting  standard  reports,  as  well  as  for  storing  and  sorting 
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data  for  customized  outputs.  Functionality  of  this  sophistication  can  promote  chat  from 
an  arbitrary  discussion  environment  to  a  formalized  reporting  tool. 

While  overall  chat  utility  can  improve  significantly  through  XML,  it  is  important 
that  no  current  chat-created  functionality  be  sacrificed.  It  is  unlikely  that  all  tactical 
information  exchanges  will  map  cleanly  into  a  highly  structured  (and  finite)  set  of 
message  types.  At  least  one  type  of  XML-based  plain-prose  message  must  be  available  to 
handle  these  types  of  conversations.  Further,  while  their  use  should  be  limited,  offline 
conversations  (i.e.,  those  unlogged  and  unseen  by  other  chatters)  have  proven  popular, 
and  seem  to  enhance  collaboration  to  some  degree.  Thus  payload  flexibility  is  essential. 

3.  Multiple  Message  Types 

The  system  will  be  able  to  process  plain  prose,  message  text  format  (MTF),  BGH 
Command  and  Control  Information  Exchange  Data  Model  (C2IEDM),  HTML,  and  BGH 
C2IEDM  reference  model  messages.  Additionally,  use  of  extensible  stylesheet  language 
transformations  (XSLT)  and  schema-governed  message  templates  will  allow  for  arbitrary 
addition,  deletion,  and  modification  of  messages. 

4.  Message  Validation  and  Data  Integrity 

All  messages  will  be  validated  against  the  schema  by  the  server.  This  will  enforce 
data  integrity  throughout  the  system  by  rejecting  invalid  messages.  Additionally,  the  use 
of  schema-governed  message  templates  and  XSLT  to  automatically  generate  HTML 
pages  for  message  composition  and  submission  can  provide  an  intuitive  method  for  users 
to  compose  and  generate  valid  messages. 

5.  BGH  Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM)  Compatibility 

Message  fields  that  correspond  to  BGH  C2IEDM  elements  will  be  compatible 
with  the  BGH  C2IEDM  architecture  [C2IEDM  2004].  XSLT  will  be  used  as  required  to 
map  tactical  chat  messages  to  the  BGH  C2IEDM  schema  for  automatic  update  of  the 
BGH  C2IEDM  database.  Since  the  BGH  C2IEDM  is  essentially  a  theater-wide  tactical 
data  repository  and  clearinghouse,  BGH  C2IEDM  compatibility  provides  compatibility 
with  any  other  systems  that  rely  on  the  BGH  C2IEDM,  such  as  the  Global  Command  and 
Control  System  (GCCS)  and  the  Command  and  Control  PC  (C2PC)  system. 
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6.  MIME  Types 

Mime  types  are  used  to  describe  e-mail  attachments.  By  integrating  MIME  types 
into  a  tactical  chat  application,  the  need  for  a  separate  e-mail  system  can  be  reduced  or 
eliminated.  The  e-mail  can  be  XML-ized  and  filtered  for  a  customized  interface. 

7.  URL’s 

As  described  at  http://www.w3.org/Addressing: 

Uniform  Resource  Identifiers  (URIs,  aka  URLs)  are  short  strings 
that  identify  resources  in  the  web:  documents,  images,  downloadable  files, 
services,  electronic  mailboxes,  and  other  resources.  They  make  resources 
available  under  a  variety  of  naming  schemes  and  access  methods  such  as 
HTTP,  FTP,  and  Internet  mail  addressable  in  the  same  simple  way.  They 
reduce  the  tedium  of  "log  in  to  this  server,  then  issue  this  magic  command 
..."  down  to  a  single  click. 

The  ability  to  pass  URLs  is  a  necessary  element  of  any  Web  application, 
including  chat.  Different  URL  spaces  will  correspond  to  different  access  requirements 
and  classification  levels  of  various  tactical  networks. 

8.  Cell  Phone  SMS 

Short-message  system  (SMS)  technology  enables  short  messages  to  be  sent 
between  cellular  phones.  As  the  capabilities  and  presence  of  cell  phones  continues  to 
grow  it  is  important  to  be  able  to  communicate  from  a  chat  application  to  the  mobile  user, 
and  vice  versa. 

9.  Data  Mining 

Tag  sets  will  be  designed  to  provide  for  easily  implemented  data  mining  of  the 
chat  log.  Well-defined  tag  sets  can  effectively  apply  XSLT  and  XPath  in  culling  relevant 
elements  from  the  log  for  operational  reconstruction  and  analysis.  This  approach  might 
automatically  generate  any  imaginable  summary  report  (e.g.,  watch  turnover  summaries, 
logistics  summaries,  schedule  requests,  etc.).  From  a  watchstanders  and  analysts 
perspective,  this  truly  can  provide  a  “revolution  in  military  affairs”  for  operators. 

Reduced  tedium  in  turn  reduces  errors  and  increases  operator  effectiveness. 

10.  Non-Text  Inclusion 

The  Jabber  protocol  allows  for  non-text  content  as  a  future  enhancement.  This 
capability  may  become  practical  and  useful  in  encoding  and  transporting  audio,  video, 
whiteboard,  and  other  non-text  data  that  is  routinely  used  in  planning.  While  not 
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envisioned  as  a  replacement  for  current  video  teleconferencing  capabilities,  the 
asynchronous  nature  of  the  Jabber  protocol,  coupled  with  the  structured  data  of  schema- 
governed  XML  (not  to  mention  the  decreased  bandwidth  and  technical  overhead 
requirements)  may  make  this  an  attractive  option  in  many  circumstances. 

11.  Asynchronous 

The  military  uses  chat  in  networking  environments  where  connectivity  is  by  no 
means  guaranteed.  Because  of  this,  the  protocol  for  tactical  chat  must  be  asynchronous, 
meaning  it  cannot  crash  or  lock  the  system  if  the  chat  message  delivery  cannot  be 
completed  immediately.  When  necessary,  the  system  must  use  a  store-and-forward 
approach  to  messaging,  i.e.,  storing  messages  on  the  local  server  and  then  forwarding  or 
synchronizing  when  the  restored  connection  allows. 

12.  Launch  Synchronous  Streams 

Many  tools  that  can  enhance  the  chat  experience  use  synchronous  protocols  to 
communicate.  Because  tactical  chat  uses  an  asynchronous  protocol  it  is  necessary  that  it 
be  able  to  launch  synchronous  streams.  One  such  tool  is  the  Network  Education  Ware 
(NEW)  project  which  bundles  whiteboarding,  video  and  audio  features  in  real  time. 

More  information  can  be  found  at  http://netlab.gmu.edu/NEW/index.shtml. 

13.  Thin  Client 

A  “thin  client”  for  chat  means  that  no  applications  need  be  loaded  onto  the  client, 
and  the  user  can  conduct  a  chat  session  via  a  Web  browser.  A  thin  client  is  desirable 
because  it  requires  no  installation  and  is  easily  maintained  at  a  central  server  location.  In 
addition,  the  current  development  requirements  for  NMCI  state  that  applications  need  to 
be  Web  enabled,  consisting  of  a  server-side  component  and  a  Web-based  interface  for  the 
client  [TFWeb  2003]. 

14.  Interoperable 

Joint-  and  inter-service  forces  have  used  a  myriad  of  chat  programs  that  do  not 
interoperate  and  are  proprietary  and  expensive.  The  current  decision-support  systems 
IWS,  Groove,  and  DCTS  are  not  interoperable  and  have  forced  the  JFC  to  look  to 
standards-based  systems  as  a  replacement  [Boyd  2003].  At  sea  operators  are  currently 
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hindered  by  simultaneous  use  of  dissimilar  chat  systems.  For  ease  of  joint  and 
multinational  use,  tactical  chat  must  implement  a  standardized  system  that  can  work  with 
other  standardized  systems. 

15.  Firewall  Policy  Compatible 

Because  of  strict  DoD  firewall  policies,  many  chat  programs  are  blocked  by 
firewalls.  Tactical  chat  needs  to  run  across  an  approved  port  for  server-to-server  (S2S) 
connections.  Because  such  communications  are  XML  data,  virus  and  security  risks  are 
minimal  (or  nonexistent). 

16.  Open  Source  -  Flexible  and  Extensible 

“Open  source”  means  that  code  is  in  the  public  domain,  using  an  open  standard.  It 
enables  thorough  code  checking,  pennits  bug  correction,  and  constitutes  a  nonproprietary 
solution  that  is  both  flexible  and  extensible. 
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17.  Recommended  Technical  Requirements 

Figure  6  presents  the  recommended  technical  requirements  for  chat: 

•  Mark  up  chat  using  standardized  XML 

•  Process  plain  prose,  message-text  fonnat  (MTF),  BGH  C2IEDM,  HTML,  and 
BGH  2IEDM  reference  model  messages 

•  Use  XSLT  templates  for  arbitrary  addition,  deletion,  and  modification  of 
available  messages  as  required 

•  Validate  messages  against  a  schema 

•  Employ  BGH  C2IEDM  elements  compatible  with  the  BGH  C2IEDM 
architecture. 

•  Accept  and  store  MIME  types  and  URLs 

•  Implement  an  SMS  bridge  for  cell-phone  text  messaging 

•  Incorporate  data  mining  support  into  application 

•  Define  audio,  video,  and  whiteboarding  schema 

•  Implement  an  asynchronous  system 

•  Implement  a  thin  client  for  single  Web  browser  use 

•  Maintain  interoperability  among  clients  and  systems 

•  Maintain  firewall-policy  compatibility 

•  Choose  open-source  code  to  preclude  security  loopholes,  reduce  cost,  and 
encourage  broad  development 

Figure  6.  Recommended  technical  requirements  for  XML-based  tactical  chat. 
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E.  ADMINISTRATIVE/SOCIAL  REQUIREMENTS 

1.  Overview 

Getting  value  from  a  chat  session  is  more  than  using  the  technology  successfully. 
For  leaders,  it  requires  the  ability  to  control  the  “who,  what,  when,  where  and  why”  when 

chat  communications  take  place.  Tools  that  permit  scheduling,  role  definitions,  and  large- 

scale  discussions  can  be  built  into  a  tactical  chat  system. 

2.  Managing  Large  Discussions 

Broad  discussions  provide  unique  challenges  that  have  been  researched  and 
defined.  Chat  is  a  fonn  of  a  large-scale  discussion  and  will  therefore  benefit  from 
applying  the  best  ideas  of  large-group  management.  Some  of  these  are  frontloading, 
negotiation,  action  planning,  and  follow  up.  Below  are  some  highlighted  concepts  from 
virtualTeamworks.com  that  assist  large  group  discussions  in  a  virtual  environment: 
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•  FRONTLOADING  is  asking  questions  before  (instead  of  after)  the  learning 
experience,  in  order  to  begin  (rather  than  end)  with  reflection,  and  so  that  behavioral 
changes  can  occur  during  the  most  powerful  part  of  the  experiences. 

•  INTERVENING  is  interrupting  a  team  during  their  experience  by  taking  "timeout" 
and  asking  questions  that  get  them  back  on  track.  However,  it  is  reserved  for  times 
when  the  team  may  not  notice  their  efforts  have  stalled  and  when  interrupting  will  not 
interfere  with  their  progress  or  create  facilitator  dependence. 

•  SOLUTION-FOCUSED  QUESTIONING  centers  on  what  people  are  already  doing 
well  (not  doing  poorly)  and  exceptions  to  the  problem  (not  why  the  problem 
happens).  Therefore,  it  works  best  with  resistant  teams  in  trouble  that  may  no  longer 
be  willing  to  explore  their  difficulties. 

•  CLARIFICATIONS  are  used  with  people  or  teams  that  are  simply  uninformed. 
Clarifying  information  should  come  from  the  people  or  teams  and  not  the  facilitator. 

•  NEGOTIATION  is  used  with  people  or  teams  that  disagree.  It  proves  useful  to 
discover  what  they  really  want  and  should  be  conducted  in  a  respectful  manner  with 
their  best  interests  at  heart. 

•  REFRAMING  is  used  with  people  or  teams  that  are  consciously  opposing  change, 
and  causes  them  to  reconsider  their  behaviors,  from  fresh  perspectives  by  reviewing 
the  content  and  context  of  what  success  will  really  mean  to  them  (e.g.,  the  "confusion 
technique"  where  the  electronic  facilitator  deliberately  acts  confused  by  group  ideas). 

•  ACTION  PLANNING  is  the  detailed  preparation  of  strategies  to  create  change  and 
is  where  teams  discuss  and  record:  what  they  will  do,  why  they  will  do  it,  where  it 
will  be  done,  when  it  will  be  completed,  who  will  confirm  the  change,  and  how  they 
will  measure  the  difference.  Typically,  clients  sign  and  share  their  plans  in  public. 

•  FOLLOW  UP  is  conducted  after  the  return  back  to  work.  This  can  take  on  many 
forms  ranging  from  completing  a  work-based  project,  through  coaching  support 
communities,  to  further  training  and  simulation  events. 


Figure  7.  Concepts  that  promote  large-group  discussion  in  a  virtual  environment 
from  http://virtualTeamworks.com.  [From  Virtual  2003] 

3.  Chat  Room  Administration  and  Conduct 

The  ability  to  effectively  govern  chat-room  permissions  and  conduct  is  an 
important  aspect  of  tactical-chat  architecture.  For  instance,  defining  and  implementing 
the  roles  of  chat-room  administrator,  moderator,  contributor,  listener,  and  participant  are 
required  to  ensure  effective  sessions.  Additionally,  the  ability  to  define  room  permissions, 
delineating  who  can  participate  in  a  given  room  and  to  what  extent  (post,  monitor  only, 
no  participation,  etc.)  must  be  defined.  Finally,  rules  governing  posted  content  to  ensure 
that  relevance  and  propriety  are  the  norm. 


32 


4.  Scheduling  Chat  Sessions 

The  ability  to  schedule  chat  sessions,  either  in  advance  or  on  the  fly,  and  to 
include  participants  automatically  is  an  improvement  that  will  aid  both  deliberate  and 
crisis-provoked  planning.  Both  regular  sessions  to  support  fixed  timelines  and  ad-hoc 
meetings  in  response  to  emergent  requirements  can  be  implemented  in  the  same  manner, 
through  a  dynamic  buddy  list  based  on  areas  of  interest.  Upon  login,  users  will  indicate  or 
be  assigned  areas  of  interest  (joining  a  buddy  list  of  others  with  the  same  interests)  based 
on  their  responsibilities.  When  sessions  pertaining  to  a  specific  interest  are  scheduled,  all 
users  with  that  interest  will  be  notified,  or  possibly  brought  into  the  chat  automatically. 

5.  Recommended  Administrative  Requirements 

Figure  8  presents  the  recommended  administrative  requirements  for  chat: 

•  Define  administrator,  moderator,  author,  and  participant  roles 

•  Define  chat-room  permissions 

•  Limit  post  content  to  relevant  information 

•  Provide  an  interface  for  scheduling  chat 

•  Designate  areas  of  special  interest  for  chat 

Figure  8.  Recommended  administrative  requirements  for  XML-based  tactical  chat. 

F.  SECURITY  CONSIDERATIONS 

1.  Overview 

This  section  presents  a  simple  overview  of  security  considerations  when  using 
chat,  and  the  importance  of  code  reliability,  infonnation  assurance  (IA),  and  NMCI/IT-21 
compatibility.  The  first  section  summarizes  the  security  requirements  for  chat.  Next,  the 
importance  and  value  of  code  reliability  inherent  in  open-source  software  is  described. 
How  Information  Assurance  (IA)  ensures  the  privacy  of  chat  communications  and  meets 
specific  requirements  to  be  implemented  in  the  DoD  [DODI  5200.40]  is  then  discussed. 
The  last  section  describes  how  XTC  might  become  compliant  with  Task  Force  Web 
(TFW)  specifications. 

2.  Security  Requirements 

There  are  three  main  security  considerations  for  chat,  listed  in  Figure  9. 
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•  Code  reliability 

•  Information  assurance  (IA) 

•  NMCI/IT-21  compatibility 
Figure  9.  Security  requirements  for  chat. 

Code  reliability  means  that  the  code  performs  as  expected,  without  hidden 
backdoors  or  Trojan  horses.  Information  assurance  (IA)  guarantees  that  data  reaches  its 
intended  recipient  and  no  one  else.  Meeting  NMCI  requirements  will  permit  the  use  of 
XTC  on  Navy  networks. 

3.  Code  Reliability  -  Open  Source 

The  expectation  that  software  runs  as  advertised  without  backdoors  or  Trojan 
horses  is  an  important,  but  often  unrecognized  aspect,  of  code  reliability.  Unfortunately 
modem  programs  contain  millions  of  lines  of  code,  perhaps  hidden  by  licensing 
restrictions,  which  preclude  broad  and  thorough  evaluation  of  every  line.  A  worthy 
challenge  is  to  design  a  process  by  which  all  lines  of  code  can  be  scrutinized. 

A  major  value  of  open  source  is  that  all  code  is  subject  to  inspection  and  protected 
by  a  select  meritocracy  of  code  committers.  Changes  are  further  reviewed  by  the  open- 
source  community,  which  prevents  programmers  from  inserting  Trojan  horses  or 
backdoor  vulnerabilities.  A  caveat  regarding  back  doors  in  a  non-open  source  project  was 
given  when  Ken  Thompson,  the  creator  of  Unix,  revealed  that  a  previous  unsuspected 
back-door  vulnerability  lurked  in  every  machine  worldwide  running  Unix  [ACM  1995]. 
These  are  broad  and  important  issues.  Producing  open-source  XTC  software  has  critical 
reliability  considerations. 

4.  Information  Assurance  (IA)  -  DoD  Compatibility 

Information  assurance  (IA)  is  the  “measures  that  protect  and  defend  infonnation 
and  information  systems  by  ensuring  their  availability,  integrity,  authentication, 
confidentiality,  and  non-repudiation.  This  includes  providing  for  restoration  of 
information  systems  by  incorporating  protection,  detection,  and  reaction  capabilities” 
[DODD  8501].  It  is  imperative  that  tactical  chat  meet  the  DoD  requirements  for  IA  as  a 
prerequisite  for  its  implementation. 
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To  achieve  DoD  approval,  tactical  chat  must  attain  a  System  Security 
Authorization  Agreement  (SSAA)  as  outlined  in  DoD  Instruction  5200.40,  DoD 
Information  Technology  Security  Certification  and  Accreditation  Process  (DITSCAP) 
[DODI  5200.40].  An  alternate  avenue  is  to  have  tactical  chat  as  an  approved  application 
in  the  NMCI  and/or  TFW  framework  instead  of  a  standalone  system.  Further  work  is 
needed  to  ensure  that  a)  chat  communications  and  b)  chat  applications  meet  these 
requirements. 

5.  Information  Assurance  (IA)  -  Ensuring  Chat  Privacy 

To  ensure  that  chat  messages  are  secure  and  unreadable  by  third  parties,  the  data 
coming  to  and  from  the  chat  client  must  be  encrypted,  best  accomplished  by 
implementing  SSL,  which  is  available  for  Jabber,  but  not  to  users  of  AIM,  ICQ,  MSN, 
and  Yahoo. 

A  good  example  of  the  information  that  can  be  gained  from  eavesdropping  on 
chat  is  evident  in  the  open  source  application  called  AIM  Sniff,  available  at 
http://www.aimsniff.com.  With  this  tool  users  can  snoop  on  anyone  using  AOL  Instant 
Messenger.  Figure  10  lists  several  capabilities  of  AIM  Sniff. 


•  Monitor  AIM  messages,  either  through  actively  sniffing  the  network,  or  by 
reading  a  “packet  capture  library”  fde 

•  Archive  messages 

•  Export  messages  to  a  MySQL  database,  flat  file,  STDOUT,  or  any  combination  of 
the  three 

•  Monitor  how  often  AIM  is  used 

•  Check  for  unlicensed/inappropriate  file  swapping 


Figure  10.  Security  vulnerabilities  of  AIM  as  exposed  by  AIM  Sniff.  [From  Rose 
2003] 


6.  NMCI/IT-21  Requirements  from  TFW 

Task  Force  Web  security  requirements  are  published  in  the  Application 
Development  Guide,  Appendix  G:  Application  Security,  provided  for  convenient 
reference  in  Appendix  F.  According  to  these  requirements,  a  secure  (future-version)  of 
XTC  is  responsible  for  securing  the  user-facing  service  (UFS)  interface.  A  possible 
solution  for  an  XTC  custom  client  is  implementing  a  portal-supplied  common  identity 
with  SSL.  This  can  ensure  a  sufficient  level  of  trust  while  enabling  the  interoperability 
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features  inherent  in  having  a  portal-common  identity.  The  goal  of  XTC  is  not  to  reinvent 
this  process,  rather  incorporate  the  methods  used  by  TFW  to  ensure  future 
interoperability  DoD  wide.  This  task  is  important  future  work. 

7.  Recommended  Security  Requirements 

The  section  discussed  security  considerations  incorporated  into  XTC  and  the 
importance  of  code  reliability,  information  assurance,  and  NMCI/IT-21  compatibility. 
Open-source  programming  ensures  that  code  reliability  is  achieved.  Information 
assurance  (IA)  requirements  using  SSL  guarantee  that  data  sent  across  chat  is  secure. 
NMCI/IT-21  compatibility  enables  XTC  implementation  into  the  TFW  portal.  Future 
work  on  XTC  and  chat-related  security  is  vitally  important. 

Figure  1 1  presents  the  recommended  administrative  requirements  for  chat: 

•  Open-source  programming  model 

•  Secure  Socket  Layer  (SSL)  capability 

•  DoD  Information  Technology  Security  Certification  and  Accreditation 
Process  (DITSCAP)  compliant  [DODI  5200.40] 

•  NMCI/IT-21  compatible 

Figure  1 1 .  Recommended  security  requirements  for  XML-based  tactical  chat. 

G.  SUMMARY 

This  chapter  defines  the  tactical,  technical,  administrative  and  security 
requirements  in  developing  a  tactical  chat  application.  The  tactical  requirements  are  to 
support  command  and  control,  operations,  and  coordination  efforts,  along  with  XML- 
izing  and  storing  the  chat  data.  Technical  requirements  are  to  broadly  fonnat  data  using 
XML  while  supporting  various  data  formats  under  an  open-source,  asynchronous, 
interoperable  environment.  Administrative  requirements  are  to  define  roles  in  military 
chat  and  enable  proper  scheduling  and  transmission  of  information.  Security 
requirements  are  to  enable  development  of  a  secure,  DoD  compliant  application. 


36 


V.  OVERVIEW  OF  JABBER  CHAT 
PROTOCOLS  AND  SOFTWARE 


A.  INTRODUCTION 

This  chapter  explains  what  Jabber  is  and  how  it  works,  giving  a  brief  history  and 
recounting  the  benefits  of  the  open-source,  extensible,  asynchronous,  secure  properties 
inherent  to  Jabber.  The  roles  of  clients  and  servers  in  a  Jabber  environment,  the  XML 
data  format,  Jabber  IDs,  the  XML  connection  stream,  and  the  attributes  of  that  stream  are 
all  explained.  Finally,  examples  of  both  successful  and  failed  Jabber  conversations  are 
provided. 


B.  WHAT  IS  CHAT? 

Chat  is  “real-time  communication  between  two  [or  more]  users  via  a  computer” 
[Webopedia  2004].  Chatting  can  be  conducted  between  two  individuals,  called  instant 
messaging  (IM),  or  a  group  of  users  in  a  chat  room,  called  conferencing.  Traditionally, 
chat  consists  of  text-based  communications  only.  However,  this  report  uses  a  broader 
definition  of  chat,  in  which  any  data  on  a  computer  has  the  potential  to  be  sent  as  a  real¬ 
time  communication. 

C.  WHAT  IS  JABBER? 

Jabber  is  an  open-standard,  XML-based  protocol  for  the  real-time  exchange  of 
messages  and  presence  between  any  two  points  on  the  Internet.  The  Jabber  protocol  is 
based  on  the  Internet  Engineering  Task  Force  (IETF)  -supported  XMPP.  [IETF  2004] 
The  first  implementation  of  Jabber  technology  is  an  IM  network  application  that  offers 
functionality  similar  to  legacy  IM  systems  such  as  IRC,  AIM,  ICQ,  MSN,  and  Yahoo. 

Jabber  was  started  by  Jeremie  Miller  in  early  1998,  and  by  late  1999  most  of  the 
Jabber  protocol  was  developed,  evolving  along  with  the  j  abberd  server  and  early 
clients  such  as  Winjab  (since  deprecated  in  favor  of  Exodus)  and  Gabber.  Jabbered  1.0 
was  released  in  May  2000,  and  in  August  of  2001,  Jabber  was  placed  under  the  auspices 
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of  the  Jabber  Software  Foundation.  As  of  4  June  2003,  the  IETF  is  looking  at  adapting 
the  Jabber  protocol  as  an  IETF-approved  instant  messaging  and  presence  technology. 

The  November  2003  issue  of  ACM  Queue  magazine  is  devoted  to  IM  and  chat. 
The  article  entitled  “Nine  IM  Accounts  and  Counting”  highlights  the  need  to  standardize 
chat  protocols  and  discusses  how  Jabber  is  taking  the  lead  in  implementing  XMPP. 

XMPP  is  the  more  complete  standard  in  that  its  work  with  the  IETF  is 
nearly  finished,  and  it  has  been  field  proven  over  the  course  of  almost  five 
years  with  nearly  10  million  users  (actually,  many  more  than  that  if  you 
consider  that  the  open-source  community  uses  XMPP  to  communicate 
with  MSN,  ICQ,  AOL,  and  Yahoo  users). 

Some  of  the  standards  bodies  have  made  the  interoperability  problem  too 
complex  by  trying  to  solve  a  rigorous,  academically  complete  set  of 
functionality  instead  of  just  defining  an  extensible  core  that  can  be  added 
to  over  time.  This  approach  leads  to  difficulties  in  incremental 
implementation  and  deployment.  Jabber  took  the  extensible  approach  with 
XMPP,  so  we  have  been  able  to  bite  off  smaller  stanzas  and  solve  them 
independently.  [ACM  2003] 


D.  STATISTICS  ON  CURRENT  CHAT  USE 

The  value  of  chat  is  evident  by  the  amount  of  commercial  use  it  gets  in  the 
corporate  world.  AOL  reports  that  more  than  a  billion  instant  messages  a  day  traveled 
across  its  AIM  network  by  the  end  of  the  first  half  of  2003.  IM  increased  by  more  than  25 
percent  since  the  end  of  2002,  and  the  amount  of  AIM  network  use  solely  by  the 
corporate  sector  likely  has  doubled.  Precise  numbers  are  often  considered  trade  secrets. 

The  search  service  Yahoo  reports  levels  for  the  end  of  June  2003  reaching  almost 
700  million  per  day — more  than  23  percent  higher  than  at  year-end  2002.  IBM  Lotus,  as 
a  provider  of  IM  solutions  targeting  the  business  marketplace,  reports  an  increase  of  more 
than  a  million  corporate  users  from  December  2002  to  June  2003.  The  current  corporate 
user  base  now  totals  more  than  9  million.  [Ritter  2003] 


E.  INTERNET  RELAY  CHAT  (IRC) 

Internet  Relay  Chat  (IRC)  was  created  in  1988  by  the  Finish  programmer  Jarkko 
Oikarinen  and  was  the  first  multi-user  chat  program.  The  original  goal  of  IRC  was  to 
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enable  the  functionality  of  a  computer  based  bulletin  board  system  (BBS)  in  real-time. 
When  it  was  discovered  traditional  BBS  functionality  didn’t  add  anything  to  the  multi¬ 
user  chat,  it  was  soon  abandoned  and  IRC  was  created.  [Oikarinen  2000] 

IRC  is  based  on  a  client-server  and  server-server  model.  An  IRC  client  program 
communicates  with  an  IRC  server,  which  is  connected  via  the  internet  to  other  IRC 
servers,  together  making  up  an  IRC  network.  The  latest  IRC  protocol  document  is  the 
Request  for  Comments  (RFC)  1459  written  in  1993;  it  is  maintained  by  the  Internet 
Engineering  Task  Force  (IETF)  and  can  be  found  at 
http://ietf.org/rfc/rfc  1459.txt?number=1459. 

IRC  is  currently  the  most  widely  used  chat  protocol  in  the  Navy.  It  is  used  by 
many  clients  including  the  proprietary  Microsoft  MS  Chat  client  which  is  included  in  the 
Navy’s  Information  Technology  21  (IT-21)  software  load.  The  advantage  of  IRC  over 
other  chat  clients  is  that  it  uses  less  bandwidth  than  competing  proprietary  clients  such  as 
Microsoft’s  Netmeeting.  [Jara  2003] 

Some  shortfalls  of  IRC  include  lack  of  support  for  the  functions  of  logging, 
timestamps,  and  authentication  that  are  required  in  the  military  environment. 

[Thomas  2003]  Additionally,  current  implementations  of  IRC  in  the  military  are 
proprietary  and  not  approved  by  the  Joint  Staff  Collaboration  Working  Group,  a  problem 
which  may  prevent  its  use  on  DoD  networks.  [Jara  2003]  Interestingly,  Jabber  allows  for 
server-side  IRC  bridges  to  provide  connections  to  an  IRC  network  if  required. 


F.  ADVANTAGES  OF  JABBER 

The  four  main  advantages  of  Jabber  are  that  it  is  open  standard,  extensible, 
asynchronous,  and  secure.  Because  Jabber  includes  open-source  implementations,  it  is 
free  of  charge  and  has  the  advantages  of  open-source  projects,  which  include  reliability 
and  security  [Wheeler  2003].  Composable  commercial  implementations  are  also  available 
if  needed.  The  extensible  characteristics  of  Jabber  allow  the  user  to  harness  the  power  of 
XML  namespaces  by  extending  the  Jabber  protocol  for  custom  functionality.  To  increase 
interoperability,  common  extensions  are  managed  by  the  Jabber  Software  Foundation 
(JSF)  found  at  http://www.jabber.org. 
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The  Jabber  protocol  is  asynchronous,  meaning  that  messages  can  be  stored  at  the 
local  server  and  forwarded  once  connected.  Jabber  provides  security  by  allowing  servers 
to  be  isolated  from  the  public  Jabber  network.  Many  server  implementations  use  secure  - 
socket  layers  (SSL)  for  client-server  communications,  and  numerous  clients  support 
Pretty  Good  Privacy/Gnu  Privacy  Guard  (PGP/GPG)  for  end-to-end  encryption;  more 
robust  security  using  simple  authentication  security  layer  (SASL)  and  session  keys  is 
under  development. 


G.  JABBER  CLIENT/SERVER  RELATIONSHIP 

Jabber  is  not  a  direct  peer-to-peer  (P2P)  architecture,  but  rather  is  both  client- 
server  and  server-server  oriented.  The  default  for  a  Jabber  client  is  to  connect  to  a  Jabber 
server  on  a  TCP  socket  over  port  5222.  This  connection  is  always  on  for  the  life  of  the 
client's  session  on  the  server.  When  sending  a  message,  it  goes  from  the  sender  to  the 
sender’s  server.  If  connected  to  the  network,  the  sender’s  server  then  sends  the  message 
to  the  recipient’s  server,  typically  over  port  5269,  which  forwards  it  to  the  recipient.  If  the 
recipient  is  unavailable  or  the  requested  Jabber  server  cannot  be  found,  the  message  is 
stored  and  later  forwarded  when  possible. 
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Jabber  Server  Jabber  Server 


Userl  @xchat.Moveslnstitute.org  User2@surfaris.cs.nps.navy.mil 

figure  12.  A  diagram  showing  the  flow  of  a  chat  message  from  a  client  to  a  server 
and  then  to  the  intended  recipient. 

Any  domain  can  run  a  Jabber  server.  Each  server  functions  independently  of  the 
others  and  maintains  its  unique  user  list.  If  server-to-server  communications  are  enabled, 
a  Jabber  server  can  talk  to  any  other  Jabber  server  that  is  accessible  via  its  network.  A 
particular  user  is  associated  with  a  specific  server,  either  through  registration  with  a 
service  provider  or  administrative  setup  within  an  enterprise. 

A  Jabber  client  is  simple.  It  communicates  with  a  Jabber  server  over  TCP  sockets 
and  parses  and  interprets  well-formed  XML  document  fragments  (sometimes  call  “Jabber 
stanzas”)  over  that  XML  stream.  A  Jabber  client  understands  the  core  Jabber  data  types: 
message,  presence,  and  iq.  In  practice,  many  of  the  low-level  functions  of  the  client  (e.g., 
parsing  XML  and  understanding  the  core  Jabber  data  types)  are  handled  by  Jabber  client 
libraries,  enabling  client  developers  to  focus  on  the  user  interface. 
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H.  XML  DATA  FORMATS 


XML  is  an  integral  part  of  the  Jabber  architecture  because  it  is  of  utmost 
importance  that  the  architecture  be  fundamentally  extensible  and  able  to  express  almost 
any  structured  data.  When  a  client  connects  to  a  server,  it  opens  a  one-way  XML  stream 
from  client  to  server,  and  the  server  responds  with  a  one-way  XML  stream  from  server  to 
client.  Each  session  involves  two  XML  streams.  All  communication  between  the  client 
and  server  happens  over  these  streams,  in  the  form  of  small  snippets  (sometimes  referred 
to  as  stanzas)  of  XML.  The  following  shows  a  single  XML  stream  fragment  sent  by  a 
Jabber  client: 


<message  f rom= ' user l@xchat . moves institute . org ' 
to='user2@surfaris.cs. nps . navy.mil ' > 
<body>This  is  a  test  message . </body> 
</message> 

Figure  13.  A  sample  XML  stream. 


Jabber's  XML  format  can  also  be  extended  through  official  XML  namespaces, 
through  a  process  managed  by  the  JSF.  Custom  namespaces  for  specialized  applications 
can  be  created  without  any  required  standardization  process  or  coordination. 


I.  JABBER  ID  (JID) 

A  Jabber  ID  (JID)  is  easy  to  remember  and  uniquely  identifies  individual  objects 
or  entities  for  communicating  instant  messages  and  presence  information.  Jabber 
addresses  are  of  the  same  form  as  e-mail  addresses  and  are  flexible  enough  to  include 
other  IM  and  presence  schemes.  Each  Jabber  ID  (JID)  contains  a  set  of  ordered  elements. 
The  JIDs  are  formed  of  a  domain,  node,  and  resource  in  the  following  format: 

[node@]domain[/resource] 
brutzman@xchat .  Mo  veslnstitute .  org 
dadevos@surfaris.cs.nps.navy.mil 
Figure  14.  Examples  of  Jabber  IDs. 

The  domain  name  is  the  primary  identifier.  It  represents  the  Jabber  server  to 
which  the  entity  connects.  Every  usable  Jabber  domain  should  resolve  to  a  fully  qualified 
domain  name.  The  node  is  the  secondary  identifier,  representing  the  user.  All  nodes  are 
found  within  a  specific  domain.  However,  the  node  is  optional,  and  a  specific  domain 
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(e.g.,  Conference  .  j  abber  .  org>)  is  a  valid  Jabber  ID.  The  resource  is  an  optional 
third  identifier.  All  resources  belong  to  a  node.  Within  Jabber,  the  resource  is  used  to 
identify  specific  objects  that  belong  to  a  user,  such  as  devices  or  locations.  Resources 
enable  a  single  user  to  maintain  several  simultaneous  connections  to  the  same  Jabber 
server;  examples  might  be  <brutzman@xchat .  Moveslnstitute  .  org/Exodus> 
vs.  <brutzman@xchat .  Moveslnstitute  .  org/Rhymbox>. 


J.  XML  CONNECTION  STREAM 

On  connecting  to  a  host,  a  node  initiates  an  XML  stream  by  sending  a  properly 
namespaced  <stream:stream>  tag,  and  the  host  replies  with  a  second  XML  stream  back  to 
the  node.  Within  the  context  of  an  XML  stream,  a  sender  is  able  to  route  a  discrete 
semantic  unit  of  structured  infonnation  to  any  recipient.  This  unit  of  structured 
information  is  a  well-balanced  XML  stanza,  such  as  a  message,  presence,  or  IQ  stanza. 
These  stanzas  exist  at  the  direct  child  level  (depth=l)  of  the  root  stream  element.  The 
start  of  any  XML  stanza  is  unambiguously  denoted  by  the  element  start  tag  at  depth=l 
(e.g.,  <presence>)  and  the  end  of  any  XML  stanza  is  unambiguously  denoted  by  the 
corresponding  close  tag  at  depth=l  (e.g.,  </presence>).  Each  XML  stanza  may  contain 
child  elements  or  CDATA  sections  as  necessary,  to  convey  the  desired  information  from 
sender  to  recipient.  The  session  is  closed  at  the  node's  request  by  sending  a  closing 
</stream:stream>  tag  to  the  host. 

Thus  a  node's  session  with  a  host  can  be  seen  as  two  open-ended  XML  documents 
that  are  built  up  through  the  accumulation  of  the  XML  stanzas  that  are  sent  over  the 
course  of  the  session.  In  essence,  an  XML  stream  acts  as  an  envelope  for  all  the  XML 
stanzas  sent  during  a  session.  Closing  a  session  completes  the  aggregated  XML 
document. 
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<!-- - __> 

open  stream 

< ! — - — > 

<message  to= ' ' > 

<body/> 

</message> 

< ! — - — > 

<presence  to= ' ' > 

<show/> 

</presence> 

<i — - — > 

<iq  to= ' ' > 

<query/> 

</iq> 

<i — - — > 

close  stream 

<!-- - __> 

Figure  15.  Example  fragment  from  a  Jabber  XML  stream. 


XML  streams  function  as  containers  for  any  XML  stanzas  sent  asynchronously 
between  network  endpoints.  XML  streams  are  used  for  the  following  types  of 
communication:  node  to  host  "jabbenclient";  host  to  host  "jabbenserver";  and  service  to 
host.  In  a  service-to-host  communication,  the  service  initiates  communications  to  the  host 
with  “jabber:component:accept,”  and  the  host  initiates  communications  to  the  service 
with  “jabber:component:connect.”  These  usages  are  differentiated  through  the  inclusion 
of  a  namespace  declaration  in  the  stream  from  the  initiating  entity,  which  is  mirrored  in 
the  reply  from  the  receiving  entity. 

XML  streams  are  used  to  transport  a  subset  of  XML  and  have  specific 
restrictions.  XML  streams  should  not  contain  processing  instructions,  undefined  entities, 
comments,  or  DTDs.  Any  non-XML  data  inside  the  stream  is  ignored. 


K.  ATTRIBUTES  OF  THE  JABBER  STREAM  ELEMENT 

Stream  elements  contain  three  attributes:  to,  from,  and  id.  The  to  element  is 
from  the  initiating  entity  to  the  receiving  entity,  and  is  set  to  the  JID  of  the  receiving 
entity.  The  f  rom  element  is  sent  by  the  receiving  entity  to  initiating  entity,  and  is  set  to 
the  JID  of  the  receiving  entity,  granting  access  to  the  initiating  entity.  The  id  element  is 
sent  by  the  receiving  entity  to  the  initiating  entity.  It  is  a  unique  identifier  created  by  the 
receiving  entity  to  function  as  a  session  key  for  the  session.  The  following  table  shows 
what  action  is  taken  when  receiving  the  different  stream  elements: 
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Element 

Initiating  to  Receiving 

Receiving  to  Initiating 

to 

JID  of  Receiver 

Ignored 

from 

Ignored 

JID  of  Receiver 

id 

Ignored 

Session  Key 

Figure  16.  Correct  responses  to  Jabber  stream  elements. 


The  'xmlns'  namespace  declaration  is  required  and  is  used  in  both  XML  streams  in 
order  to  scope  the  allowable  first-level  children  of  the  stream  element  for  both  streams. 
This  namespace  declaration  must  be  the  same.  The  ’xmlns: stream’  namespace  declaration 
is  also  required  in  both  XML  streams.  The  value  must  be 
“http  ://etherx.j  abber.org/ streams.  ” 

L.  JABBER  STREAM  ERRORS 

The  stream  element  may  also  contain  <stream:error/>  as  a  child  element, 
signifying  that  a  stream-level  error  has  occurred.  A  variety  of  errors  may  occur  at  the 
level  of  the  stream.  The  following  table  lists  possible  stream  errors: 

•  Sending  of  invalid  XML 

•  Shutdown  of  a  host 

•  Internal  server  error  such  as  the  shutdown  of  a  session  manager 

•  An  attempt  by  a  node  to  authenticate  as  the  same  resource  that  is  currently  connected. 
Figure  17.  Possible  reasons  for  a  stream  error  in  a  Jabber  XML  stream. 

If  an  error  occurs  at  the  level  of  the  stream,  the  entity  (whether  initiating  or 
receiving)  that  detects  the  error  should  send  a  stream  error  to  the  other  entity  specifying 
why  the  streams  are  being  closed,  closing  with  a  </stream:stream>  tag. 

<stream: stream  ...> 

<stream: error>  Error  message  (e.g.,  "Invalid  XML")  </stream: error> 

</stream: stream> 

Figure  18.  Example  of  a  stream-error  closing  stream. 
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M.  JABBER  EXAMPLES 


The  following  two  examples  show  a  successful  and  a  failed  Jabber  conversation: 

NODE : <stream: stream 
to= ' host ' 

xmlns= ' j  abber : client ' 

xmlns : stream= ' http : / /ether x . j  abber . org/ streams ' > 

HOST : <stream: stream 
f rom= ' host ' 
id=' id_123456789 ' 
xmlns = ' j  abber : client ' 

xmlns : stream= ' http : / /ether x . j  abber . org/ streams ' > 

NODE : <message  f rom= 1 node@host '  to= ' receiving-ID ' > 

NODE:  <body>This  is  a  test  message.  </body> 

NODE : </message> 

HOST : <message  f rom= ' receiving-ID '  to= ' node@host ' > 

HOST:  <body>I  received  the  message.  </body> 

HOST : </message> 

NODE :</ stream : stream> 

HOST : </ stream : stream> 

Figure  19.  A  successful  Jabber  conversation:  message  sent,  received  and 
acknowledged. 


NODE : <stream: stream 
to= ' host ' 

xmlns = ' j  abber : client ' 

xmlns : stream= ' http : / /etherx . j  abber . org/ streams ' > 

HOST : <stream: stream 
f rom= ' host ' 
id=' id_1234  5678  9  ' 
xmlns= ' j  abber : client ' 

xmlns : stream= 1  http : / / etherx . j  abber . org/ streams ' > 

NODE : <message>lt; body>Bad  XML,  no  closing  body  tag ! </message> 

HOST : <stream: error>Invalid  XML</stream: error> 

HOST :</ stream : stream> 

Figure  20.  A  failed  Jabber  conversation:  Client  post  message  was  malformed,  XML 
thus  invalid,  resulting  in  error  response. 

N.  SUMMARY 

Jabber  is  a  recently  developed,  open-standard  chat  protocol  that  enables  an 
asynchronous  XML-formatted  conversation.  It  is  reliable,  secure,  and  can  be  extended 
and  customized  to  meet  tactical-chat  functionality.  This  chapter  describes  the  value  of 
chat,  XML,  and  Jabber.  It  also  explains  JIDs  and  Jabber  XML  streams. 
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VI.  JABBER  DEPLOYMENT  GUIDE 


A.  INTRODUCTION 

This  chapter  shows  how  to  configure  a  Jabber  client  and  server  and  send  an  XML 
message  to  a  Jabber  IM  client.  The  first  section  includes  the  steps  needed  to  install  a 
client  and  an  evaluation  of  three  Jabber  clients.  The  next  section  describes  how  to  install 
a  Jabber  server,  in  particular  describing  how  NPS  installed  the  j  abberd  daemon  on  the 
hosts  surf  aris  .  cs  .  nps  .  navy .  mil  and  xchat .  Moveslnstitute  .  org.  The 
last  section  describes  how  to  configure  a  Web  server  with  Tomcat  and  Java  servlets  to 
support  an  HTTP  post  to  a  Jabber  server. 

B.  JABBER  CLIENT  SET-UP 

The  following  section  gives  step-by-step  instructions  on  how  to  install  and 
configure  a  Jabber  client.  Three  clients  are  also  evaluated:  Rhymbox,  Exodus,  and 
BuddySpace. 

1.  Download  a  Client 


The  first  step  is  to  download  a  Jabber  client.  The  following  table  lists  Jabber 
clients  tested  for  Windows  as  part  of  this  report,  and  where  they  can  be  found: 


BuddySpace 

httD://buddvsnace. sourceforge.net 

Exodus 

http://www.  iabberstudio.org/nroiects/exodus/releases 

Rhymbox 

httn://www.rhvmbox.com/download 

Figure  2 1 .  List  of  tested  Jabber  clients  and  source  locations. 


Rhymbox  and  Exodus  are  used  primarily  in  this  report  because  they  currently 
have  the  most  refined  interface  and  also  include  user-friendly  XML-aware  debug 
windows.  Additional  chat  clients  can  be  found  at  http://www.jabber.org. 

2.  Log  onto  a  Jabber  Server 

The  next  step  is  to  log  onto  a  Jabber  server.  The  user  needs  network  access  to  a 
Jabber  server  in  order  to  create  a  Jabber  account.  Currently  there  are  two  NPS  servers, 
surf  aris  .  cs  .  nps  .  navy .  mil  inside  the  firewall  and 

xchat .  movesinstitute  .  org  outside.  These  servers  are  linked  via  S2S  connection 
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through  the  NPS  firewall.  Clients  cannot  log  in  across  the  firewall  boundary,  requiring 
them  to  use  a  server  on  the  same  side.  For  example,  a  client  inside  the  NPS  firewall  can 
only  log  into  Jabber  servers  inside  the  firewall,  and  a  client  outside  the  firewall  can  only 
log  into  Jabber  servers  outside  the  firewall.  However,  Jabber  servers  can  communicate 
with  each  other  via  an  S2S  port  that  has  been  opened  in  the  firewall.  This  allows  clients 
who  have  logged  into  a  protected  NPS  Jabber  server  to  send  messages  to  clients  logged 
into  Jabber  servers  outside  the  firewall  and  vice  versa.  Because  only  plain- text  XML 
messages  can  pass  over  this  channel,  virus  threats  are  greatly  reduced  to  the  point  of 
being  negligible.  There  is  also  an  experimental  server  for  NPS  users  at 
dickdale  .  cs  .  nps  .  navy .  mil  and  a  server  hosted  by  FNMOC  at 
j  abber . metnet . navy .mil. 

In  addition  to  the  server  name,  the  user  needs  to  know  the  port  number.  The 
default  for  the  Jabber  client-to-server  protocol  is  port  5222;  however  FNMOC’s  server 
uses  port  8080.  The  default  S2S  port  number  is  5269.  Below  is  a  topology  of  available 
servers  at  NPS. 
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Server  Topology 


dickdale.cs.nps.navy.mil 


surfaris.cs.nps.navy.mil 


S2S  port  5269 


S2S  port  5269 


jabber.metnet.navy.mil 
port  8080 


xchat.Moveslnstitute.org 


Figure  22.  Diagram  of  the  server  topology  inside  and  outside  the  firewall  at  NPS. 


To  set  up  a  Jabber  account  inside  the  firewall,  enter  the  following  information  (if 
outside  the  firewall  substitute  surf  aris  .  cs  .  nps  .  navy .  mil  with 
xchat .  movesinstitute  .  org): 


Profile 

Create  a  Username:  (User  choice) 

Server:  surfaris.cs.nps.navy.mil 

Password :  (User  choice  -  must  have  one) 

Connection 
Type :  Normal 

Host :  surfaris.cs.nps.navy.mil  (Same  as  Server) 
Port :  5222 


Figure  23.  Settings  for  logging  into  a  Jabber  server. 
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When  logging  into  the  server  for  the  first  time,  users  must  agree  to  create  a  new 
account.  Some  clients  give  the  option  of  filling  out  additional  information  on  first  login. 
Such  setup  can  also  be  performed  at  a  later  time. 

3.  Add  an  Individual  to  a  Buddy  List 

To  add  an  individual  to  a  buddy  list,  the  user  will  need  to  know  the  full  user  name 
and  server  name.  Then  enter  the  person’s  JID:  user  Name  @  server  Name,  which  looks 
exactly  like  an  e-mail  address.  Jabber  will  not  add  the  user  to  a  buddy  list  until  it  receives 
confirmation  from  the  identified  individual.  For  more  information  on  JIDs,  see  the  Jabber 
IDs  section  in  Chapter  IV. 

4.  Join  a  Conference  Room 

The  next  step  is  to  join  a  conference  room.  The  rooms  have  the  same  name  and 
server  location,  whether  joined  from  inside  or  outside  the  firewall.  In  order  to  join  a 
conference  room,  enter  the  conference  room’s  JID  into  the  Jabber  client.  The  menu 
options  for  this  process  may  differ  slightly,  depending  on  the  client.  For  example,  in 
Rhymbox  click  Find  a  Conference  Room  then  Join  Room,  and  then  enter  the  room  name 
savage  or  xj  3d .  The  JIDs  for  rooms  of  interest  are: 


Chat  Server 

Conference  Room 

JID 

XChat 

Savage 

savage@ conference .xchat .moves institute . org 

XChat 

Xj3d 

xj 3 d@ conference. xchat .moves institute .org 

Figure  24.  Conference  room  JIDs  of  interest. 


When  joining  a  conference  room,  a  new  JID  is  created  for  the  user’s  conference 
room  session.  The  JID  is  the  conference  Room  Name@  conference  Server  JID/user 
Name.  Depending  on  the  client,  the  user’s  nickname  is  set  in  the  users  profile  or  upon 
logging  into  the  conference  room. 

5.  Client  Comparison 

The  different  features  of  the  clients  are  shown  in  Figure  25  below,  excerpted  from 
the  Jabber  clients  support  page  at  http://www.iabber.org/user/clientlist.php.  Figure  26 
explains  what  is  meant  by  each  of  the  client  features  categories  below. 
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Client 

Basic  Chat 

Groupchat 

Headline  Support 

Browser  Support 

x:data  Support 

Unicode  Support 

File  Transfer 

Message  History 

Invisible  Support 

Proxy  Support 

SSL  Support 

Sound  Notifications 

Emoticons 

Skinning 

Reply  Indicator 

Exodus 

it 

# 

* 

* 

U? 

Q 

it 

Q 

Q 

* 

* 

RhymBox 

O 
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Ik 

o 

O 

* 

& 

O 

ft 

Q 

Q 
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o 

* 

c? 

BuddySpace 
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Q 
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Q 

& 

Q 

& 

Q 

c? 

Q 

a 

c? 

* 

Legend 

Support  Level 

& 

Full 

o 

Partial 

_ 

None 

Figure  25.  The  features  currently  implemented  in  the  Jabber  clients  used  in  this 
report.  [From  Client  2004] 


Client  Features 

Description  of  Features 

Basic  chat  (also  known  as  IM) 

Peer  to  peer  chat. 

Groupchat  (superseded  by  Multi-User 
Chat  and  also  known  as  conferencing) 

Multiple  users  reading  and  chatting 
simultaneously. 

Headline  Support 

Headlines  consist  of  a  URL  and  a  subject. 

Browser  Support  (replaced  by  disco) 

Service  Discovery 

httn://www. iabber.org/iens/ieD-0030.html. 

x:data  Support 

Generic  data  gathering/reporting  in  Jabber. 

URL:  httn://www. iabber.org/iens/ien- 
0004.html. 

Unicode  Support 

Allows  multiple  languages  to  be  used. 

File  Transfer 

Send  fdes. 

Message  History 

Creates  a  message  history  that  can  be  saved. 

Invisible  Support 

Track  presence  type. 

Proxy  Support 

Allows  the  use  of  a  proxy  in  connection 
settings. 

SSL  Support 

Allows  the  use  of  secure  socket  layer  (SSL)  in 
connection  settings. 

Sound  Notifications 

Plays  sound  when  message  received 

Emoticons 

Replaces  special  key  strokes  with  pictures 

Skinning 

Allows  the  user  to  change  the  look  of  the  client 
with  a  “skin.” 

Reply  Indicator 

Message  events  such  as  “Is-Composing.” 

Figure  26.  Description  of  the  features  that  are  currently  implemented  in  Jabber 
clients. 


51 


6.  Rhymbox 

RhymBox  is  a  Jabber  client  for  chat  with  a  Jabber  server  and  can  be  found  at 
http://www.rhvmbox.com.  RhymBox  has  a  shared-source  license  and  is  written  in  C++. 
The  first  screen  in  Rhymbox  is  the  login  screen,  which  is  easy  to  use  and  lists  all  user 
accounts.  Icon  images  smaller  than  8KB  can  be  used  to  simplify  user/role  login  selection. 


Figure  27.  Multiple  profiles  lets  users  have  accounts  on  multiple  servers  or  share  the 
RhymBox  application  with  others  on  the  same  computer. 


The  next  screen,  Add  a  Contact,  allows  the  user  to  search  a  directory  for  a  user’s 
name  or  type  the  JID  of  a  known  contact  in  the  username  box. 
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Figure  28.  Screen  shot  showing  how  to  add  contacts  with  the  RhymBox  client. 

The  next  screen  shows  the  user’s  contacts  and  their  on-line  status.  The  picture 
next  to  the  name  is  an  avatar  and  can  be  customized  from  the  Actions  tab.  Select 
Actions/Change  My  Avatar  if  the  picture  is  not  available,  then  the  Custom  Image  button. 
Pick  a  picture  of  type  gif,  jpg  or  png  that  is  less  than  8KB. 


Figure  29.  Above  is  a  screen  shot  showing  Jabber  contacts’  online  status  in 
RhymBox. 
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The  next  screen  is  the  standard  chat  window  for  RhymBox. 


Figure  30.  Above  is  an  example  of  a  P2P  chat  session  in  RhymBox. 


The  next  screen  lists  all  the  conference  rooms  available  and  gives  the  user  the 
number  of  people  in  each  room  plus  the  option  to  create  new  rooms. 


Figure  3 1 .  RhymBox  screen  shot  listing  available  Conference  rooms. 
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Next  is  the  screen  used  to  create  a  conference  room  that  allows  the  user  to  invite 


contacts  when  a  room  is  created. 


Figure  32.  Rhymbox  screen  used  to  create  a  conference  room. 

The  last  screen  shots  show  the  debug  feature  of  Rhymbox.  This  example  shows 
the  XML  traffic  when  a  user  logs  into  the  Jabber  server.  Note  that  SENT  :  and  RECV : 
are  interspersed  by  the  client  for  display  purposes  only.  Only  XML  tags  are  sent  over  the 
chat  channel. 
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Console 


00® 


Network  traffic: 


RECV:  <iq  id="ATECLIENT_1 "  type="result"x/iq> 

Debug  is  on 

RECV:  <presence  type="connect"/> 

SENT:  <iq  type="get"  to="xchat.  movesinstitute.  org"xquery  xmlns="jabber:iq:browse7x/iq> 

|  Clear  output  ] 

0  Break  lines 

RECV:  <iq  type="result"  to="dadevos@xchat. movesinstitute.org/RhymBox" 

from="xchat. movesinstitute. org"xservice  xmlns-'jabber: iq: browse"  type="jabber"  jid="xchat. movesinstitute. org" 
name-’Jabber  Server"> 

<service  type="jud"  jid="users.jabber.org"  name-'Jabber  User  Directory"> 
<ns>jabber:iq:search</ns> 

<ns>jabber:iq:register</ns> 

</service> 

cconference  type="public"jid="conference.  movesinstitute.  org" 
name="Conferencing"x/conference> 

</servicex/iq> 

SENT:  <iq  type="get"xquery  xmlns="jabber:iq:roster7x/iq> 

RECV:  <iq  type="result"  from="dadevos@xchat. movesinstitute. org/RhymBox"xquery 
xmlns="jabber:iq:roster"xitem  jid="brutzman@xchat.  movesinstitute.  org"  subscription="none" 
ask="subscribe"x/item></queryx/iq> 

SENT:  <iq  type="get"  to="brutzman@xchat. movesinstitute. org"xvCard  xmlns="vcard-temp7x/iq> 

SENT:  <presence><x 

xmlns="jabber:x:avatar"xhash>4448c00da800da7405e40863326ed75197dd50b1</hashx/x><priority>8</priority> 

</presence> 

EVNT:  HTTPEngine  listening  at  port  4612 

RECV:  <iq  type="result"  to="dadevos@xchat.movesinstitute.org/RhymBox" 
from="brutzman@xchat.  movesinstitute.  org"x/iq> 

Figure  33.  Debugging  a  chat  session  with  RhymBox  reveals  the  underlying  XML. 
chat  messages  that  are  sent  and  received.  SENT:  and  RECV:  entries  are  for 
display  only  and  not  included  in  the  underlying  XML  stream. 


The  features  of  RhymBox  are  shown  in  Figure  34. 

•  Choice  of  chat  or  message  style 

•  Typing  notification 

•  File  transfer  ability 

•  Customizable  avatars 

•  Customizable  emoticons  (hundreds  included) 

•  Text  conferencing  (group  chat) 

•  Message  history  logging 

•  Interoperability  with  MSN,  Yahoo,  AIM  and  ICQ 

•  Sound  alerts 

•  Multiple-profile  settings 

•  Auto-reconnection 

•  SOCKS  proxy  support 

•  Secure  encryption  (SSL) 

•  No  adware  or  spyware 

•  No  cost 

Figure  34.  List  of  advantageous  RhymBox  features. 
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This  chat  client  is  easy  to  download  and  install;  setup  is  intuitive  and  all  features 
work  well.  Of  the  three  chat  engines  examined  in  this  report,  RhymBox  is  easiest  to  use. 

7.  Exodus 

Exodus  is  a  Jabber  client  for  chat  with  a  Jabber  server  and  can  be  found  at 
http://exodus.iabberstudio.org.  Exodus  has  a  GNU  Public  License  (GPL)  and  is  written  in 
Delphi.  The  first  screen  in  Exodus  is  the  login  screen.  When  creating  a  new  account, 
Exodus  asks  user  for  additional  information.  This  feature  is  optional  to  Jabber,  and  can  be 
done  at  a  later  time. 


Figure  35.  Multiple  profiles  let  users  share  Exodus  with  others  on  the  same  computer 
or  have  accounts  on  multiple  servers. 


The  next  step  is  the  Add  a  Contact  screen,  in  which  the  user  adds  contacts  by 
entering  the  contacts  JID  in  the  Contact  ID  box,  along  with  nicknames.  Exodus  also 
provides  group  contacts. 
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Add  Contact 


Contact  Type:  jabber 

Contact  ID: 

Nickname: 

Group: 


Friends 


Add  a  new  Group 


urfari 


OK 


Cancel 


Figure  36.  Screenshot  of  the  Add  Contact  feature  in  Exodus. 


The  next  screen  shows  all  user  contacts  and  their  on-line  status.  A  yellow  light 
bulb  indicates  that  the  contact  is  available  and  on-line.  A  question  mark  indicates  the 
contact  has  not  yet  accepted  the  invitation  to  be  a  buddy. 


Figure  37.  Screenshot  showing  contacts’  online  status  in  Exodus. 


The  next  screen  is  the  standard  chat  window  for  Exodus. 
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Figure  38.  Example  of  a  P2P  chat  session  in  Exodus. 


At  this  time,  Exodus  does  not  list  conference  rooms  available.  The  next  screen  is 
used  for  joining  a  conference  room,  requiring  the  user  to  enter  the  room  name,  server,  and 
a  nickname  for  use  in  the  room.  The  password  block  is  for  the  room  password,  and 
should  not  be  entered  unless  the  room  was  password-protected  when  created. 


Figure  39.  Screenshot  of  the  logon  procedure  for  joining  a  chat  room  in  Exodus. 
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The  next  screen  shots  show  the  debug  feature  of  Exodus.  This  example  shows  the 
XML  traffic  when  a  user’s  presence  is  updated. 


Figure  40.  Debugging  a  chat  session  with  Exodus. 

Two  nice  features  of  Exodus  are  the  tab  feature  for  displaying  multiple  windows 
and  the  ability  to  add  contacts  from  the  conference  room  screen  by  right-clicking  their 
name  and  sending  them  a  JID.  Below  are  screenshots  depicting  these  features. 


Subiectsavaae:  XML-based  T actical  Chat  for  l/ITSEC  2003 


[1 1 :09  AM]  Dan  has  entered  the  room. 

[11:09  AM]  savage:  Scenario  Authoring  and  Visualization  for  Advanced  Graphical  Environments. 

[5:47  PM]<brutzman>  hello  from  rhymbox 
[5:48  PM]<brutzman.exodus>  hello  from  exodus 
[5:49  PM]<brutzman>  connected  from  inside  NPS  via  surfaris  -  woo  hoo! 

[5:50  PM]<HTSECServlet>  Category  :  Chat  -  Server 
To  :  Savage  Group  (NPS) 

From  :  McGregor,  Don  (NPS) 

Report :  Type  bug  report  here. 

[5  51  PM]<HTSECServlet>  Category  :  Chat  -  Server 
To  :  McGregor,  Don  (NPS) 

From  :  Brutzman,  Don  (NPS) 

Report  :  looks  like  the  IITSECServlet  announces  its  presence  once  tickled,  after  a  server  reboot. 

[7:35  PM]<mcgredo>  Well,  finally  got  that  working. 

[8:52  PM]<mcgredo>  From  NPS. 

[7:28  AM]<daryl_surfaris>  sending  from  Spangel,  rm  263 
[7  28  AM]<brutzman.exodus>  hi  Daryl,  i'm  home  but  packing  up  soon 
[7  28  AM]<daryl_surfaris>  it  would  be  good  to  be  able  to  see  the  list  of  chatrooms  availabe  on  Xchat...  maybe  a 
technical  constraint 

[7:47  AM]<daryl_surfaris>  Don  (M),  is  there  a  way  to  connect  to  xchat.movesinstitute.org  from  NPS  network 
(internal  or  dialup)?  for  admin  purposes? 

[7:47  AM]<daryl_surfaris>  going  to  class  now. 

[10:42  AM]<brutzman.exodus>  hi  Dan! 

[10:43  AM]<Dan>  This  works  great  from  inside  NPS!  THX  Don 

[11:09  AM]  The  topic  has  been  set  to:  savage:  XML-based  Tactical  Chat  for  l/ITSEC  2003 


^brutzman.  ex... 
I^Dan 
9  dtdavis 


Figure  4 1 .  Add  a  contact  while  in  a  conference  room  by  right-clicking  his  name  and 

sending  him  a  JID. 
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The  feature  in  Exodus  that  sets  it  apart  from  Rhymbox  is  the  ability  to  turn  on 
timestamps.  At  the  Tools/Preferences/Messages/Message  Options  tab,  check  the 
Timestamp  Messages  box.  To  set  the  timestamp  to  display  a  date  such  as  12/18/03  8:26 
am,  type  the  following  undocumented  format  into  the  Format  field  [  m/d/y  h  :  mm 
am/pm  ],  as  seen  in  Figure  42. 


Figure  42.  Turn  on  the  timestamping  feature  in  Exodus  to  date  chat  messages. 
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Figure  43.  Selecting  the  Dock  Windows  and  Use  Tabs  option  in  Exodus  layers 

windows,  which  organizes  the  chat  window  and  allows  easy  switching  between 
sessions. 

To  use  SSL  connections  with  Exodus,  the  SSL  DLLs  need  to  be  downloaded. 
This  zip  package  contains  two  DLLs,  which  must  be  placed  in  the  directory  where 
Exodus  is  installed.  To  minimize  download  size,  these  DLLs  are  not  included  by  default. 
The  DLLs  can  be  found  at  http://exodus.iabberstudio.org/indy  openssl096g.zip  (or 
simply  via  http://exodus.jabberstudio.org). 

Other  helpful  features  are  the  echo  command,  which  repeats  what  is  typed,  and 
automatic  logging,  which  saves  chat  history  in  HTML  with  time  stamps. 

8.  BuddySpace 

BuddySpace  is  a  Jabber  client  for  chatting  with  a  Jabber  server,  found  at 
http://buddyspace.sourceforge.net.  BuddySpace  has  a  Jabber  open-source  license  (JOSL) 
and  is  written  in  Java,  which  is  of  interest  for  possible  software  customization.  The 
BuddySpace  initial  login  screen  requires  the  user  to  retype  his  information  each  time  he 
changes  accounts,  which  is  not  a  good  feature. 
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Figure  44.  The  BuddySpace  login  screen  requires  the  user  to  retype  all  information 
when  switching  accounts. 


When  one  tries  to  open  a  conference  room  with  BuddySpace,  the  error  "Error 
501:  Not  Implemented!"  appears.  According  to  David  Sutton  (screen  name  “peregrine”), 
the  creator  of  MU-conference  protocol,  BuddySpace  is  currently  using  the 
“conferencing”  protocol  to  connect  to  conference  rooms.  This  was  never  endorsed  as  a 
protocol,  although  the  conference  vO. 4  jabber  component  does  accept  it.  It  does  not  have 
the  same  functionality  as  “groupchat,”  however,  as  groupchat  doesn't  use  the 
jabber:iq:conference  calls  to  check  and  request  rooms.  If  it  were  supporting  groupchat,  it 
would  connect  quite  happily  to  MU-conference,  as  it  was  designed  to  handle  both  MUC 
and  groupchat.  [Sutton  2003] 

BuddySpace  did  not  support  SSL  at  the  time  of  testing. 
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9.  Observations  from  Using  Clients 

All  clients  feature  a  debug  window  that  allows  the  user  to  view  the  XML  network 
traffic.  Both  Exodus  and  RhymBox  allow  the  user  to  join  conference  rooms.  BuddySpace 
offers  to  let  the  user  join  a  room,  but  says  “not  implemented”  when  the  attempt  is  made, 
and  fails  to  admit  him.  BuddySpace  is  not  ready  for  tactical-chat  use. 


C.  JABBER  SERVER  SET-UP 

The  experimental  Jabber  servers  at  NPS  are  on 
surfaris.cs.nps.  navy .  mil  and  dickdale  .  cs  .  nps  .  navy  .mil.  They  are 
behind  the  NPS  firewall  and  can't  be  accessed  from  outside.  Outside  the  firewall,  two 
servers  are  available  for  testing  at  xchat .  movesinstitute  .  org  on  port  522  6  or 
j  abber  .  met  net .  navy  .mil  on  port  8  080. 

This  report  details  how  servers  were  set  up  on  Surfaris  and  xchat.  Services 
covered  include  conference  rooms,  firewalls,  logging  and  server  to  server  (S2S).  The 
following  diagram  shows  the  initial  server  setup. 
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Jabber  User 

Directories 

(JUD) 


S2S 


xml@conference.surfaris.cs.nps.navy.mil 
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Apache  http  +  Tomcat 
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Primary  JUD 


savage  room 


Xj3d  room 


conference.movesinstitute.org 


savage@conference.movesinstitute.org 


Figure  45.  Setup  summary  of  chat  servers  and  conference  rooms  on  surf  aris  and 
xchat. 


1.  Setting  Up  a  Server  on  Surf  aris 

NPS  first  attempted  to  install  the  Jabber  server  OpenIM  on  Windows,  which 
failed.  The  next  attempt  was  to  install  jabberd  1.4.2  on  Linux,  which  seems  to  be  the  most 
widely  used  Jabber  server.  The  configuration  followed  the  usual  UNIX  process  of  typing 
"configure”  in  the  distribution  directory.  This  examines  the  machine  and  builds  a 
makefile.  Once  this  is  done,  the  user  types  "make"  to  compile  the  program,  and  "make 
install"  to  install  it. 

Jabberd  uses  one  of  several  possible  databases  to  manage  data.  The  options 
include  MySQL  and  Berkeley  DB.  This  report  uses  Berkeley  DB.  The  version  of 
Berkeley  database  required  was  quite  recent,  4.2.52  or  later.  The  rpm  file  was 
downloaded  from  sleepycat  software,  which  maintains  an  open-source  version  of  the 
Berkeley  DB,  and  is  installed  it  in  the  usual  way  (rpm  -  i  anRPMFi le  .  rpm). 


65 


Server  setup  requires  making  a  directory  for  configuration,  setting  a  host  name, 
and  encryption  software  if  encryption  is  desired.  Configuration  is  done  in  part  via  the 
files  /etc/sysconf  it/ j  abber.  The  SSL  feature,  which  allows  encrypted 
communications,  was  turned  off,  but  is  installed  on  dickdale.  To  get  this  feature, 
openSSL  needs  to  be  install.  Other  configuration  files  include 
/usr/local/j abberd-1 . 4 . 2 / j  abber . xml. 

The  directory  /  u  s  r  / 1  o  c  a  1  /  j  abb  e  r  d  - 1 . 4 . 2  has  translators  for  various  chat 
programs,  including  AOL’s  and  ICQ’s.  Other  plug-ins  can  be  placed  in  this  directory 
including  one  for  conference  rooms. 

The  server  process  is  started  via  /etc/init .  d/ j  abberd.  This  process  is 
called  automatically  at  startup,  or  can  be  manually  started  or  stopped  by  directly 
executing  the  script. 

Jabberd  2.0  was  not  released  in  stable  form  at  time  of  the  initial  installation  and 
test  on  surf  ar is  (January  2004). 

2.  Setting  Up  a  Server  on  MovesInstutute.org 

Clients  and  servers  from  outside  the  firewall  cannot  connect  with  safaris  at 
this  time.  A  second  Jabber  server  was  installed  on  movesinstitute.org.  Attempts  to 
configure  both  servers  in  like  fashion  didn’t  work. 

A  few  notes  from  the  setup  of  xchat.movesinstitute.org: 

a.  DNS 

The  xchat  name  needed  to  be  paired  with  an  IP  number.  The  DNS 
provider  for  movesinstitute.org  is  zoneedit.com,  who  provide  a  nice  Web-based  interface 
for  manipulating  DNS  tables:  DNS  simply  matches  a  name  with  an  IP  number.  The 
location  of  the  IP  number  is  irrelevant.  The  following  entry  was  made  to  the  list  of  hosts 
in  the  MovesInstitute.org  domain: 


Host  Name 

IP 

confemce  .xchat. movesinstute  .org 

12.213.189.186 

xchat  .mo  vesinstitute .  org 

12.213.189.186 

Figure  46.  IP  addresses  needed  to  install  Jabber  server  on  MovesInstitute.org. 
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The  12.213.189.186  IP  is  dynamically  assigned  by  comcast.net  to  a  home 
computer  via  DHCP.  DHCP-assigned  IPs  can  be  fairly  stable  over  long  periods  of  time  in 
the  right  conditions.  Comcast  has  their  DHCP  server  configured  to  hand  out  leases  for 
four  days’  duration,  and  because  of  the  way  the  DHCP  protocol  works,  this  IP  is 
constantly  renewed. 

b.  Firewall 

The  xchat. Moves  Institute  .  org  machine  contains  a  firewall.  Since 
it  is  exposed  to  the  Internet  at  large,  it  constantly  fields  probes  from  people  or  worms 
looking  for  a  way  in.  This  usually  manifests  itself  as  probes  for  Microsoft  Internet 
Information  Server  (IIS)  weaknesses,  but  other  port  scans  go  on  as  well.  For  example, 
putting  up  a  Web  server  shows  these  log  entries: 

12.229.49.123  -  -  [ 02/Sep/2003 : 14 : 01 : 01  -0700]  "GET 
/scripts/. .%cl%lc. . /winnt/system32/cmd. exe?/c+dir  HTTP/1.0" 
404  304 


These  are  attempts  to  use  Unicode  exploits  to  compromise  a  Windows  box 
running  IIS.  Buffer-overrun  exploits  are  also  continually  attempted. 

Modern  Linux  boxes  use  iptables  firewalls.  In  this  case,  an  iptables  script 
was  configured  at  /etc/rc.d/rd.firewall-2.4  that  shut  off  all  access  to  ports  on  the  machine 
except  for  those  explicitly  allowed.  The  following  services  were  allowed: 

echo  -e  "  -  Allowing  EXTERNAL  access  to  the  WWW 

server" 

$IPTABLES  -A  INPUT  -i  $EXTIF  -m  state  --state 
NEW, ESTABLISHED, RELATED  \  -p  tcp  -s  $UNIVERSE  -d  $EXTIP  -- 
dport  80  -j  ACCEPT 

#  Let  SSH  come  in 

echo  -e  "  -  Allowing  EXTERNAL  access  to  SSH" 

$IPTABLES  -A  INPUT  -i  $EXTIF  -m  state  --state 
NEW, ESTABLISHED, RELATED  \  -p  tcp  -s  $UNIVERSE  -d  $EXTIP  -- 
dport  22  -j  ACCEPT 

#  Let  jabber  come  in 

echo  -e  "  -  Allowing  EXTERNAL  access  to  jabber" 

$IPTABLES  -A  INPUT  -i  $EXTIF  -m  state  --state 
NEW, ESTABLISHED, RELATED  \  -p  tcp  -s  $UNIVERSE  -d  $EXTIP  -- 
dport  5222  -j  ACCEPT 

#  Let  jabber  ssl  come  in 
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echo  -e  "  -  Allowing  EXTERNAL  access  to  jabber  via 

SSL" 

$IPTABLES  -A  INPUT  -i  $EXTIF  -m  state  --state 
NEW, ESTABLISHED, RELATED  \  -p  tcp  -s  $UNIVERSE  -d  $EXTIP  -- 
dport  5223  -j  ACCEPT 

The  firewall  script  was  run  from  the  init.d  directory  script  firewall-2.4, 
which  was  turned  on  via  the  chkconfig  command. 

c.  Jabberd 

Jabber  itself  was  installed  at  /usr/local/ j  abber.  The  main 
configuration  file  is  jabber.xml.  The  jabberd  daemon  is  started  via  the  jabberd  script  in 
/etc/ ini  t .  d,  or  via  the  chkconfig  command.  The  compilation  of  jabberd  is  labor 
intense.  In  the  jabber  directory,  type: 

[jabber]#  ./configure  —  enable-openssl  — with-openssl=/usr/local/ssl/usr/local/ssl 

This  directory  contains  Openssl  0.9.6.  Jabber  is  picky  about  the  version  of  SSL  used, 
returning  compilation  errors  if  a  more  modern  version,  such  as  that  installed  on  Linux  by 
default,  is  attempted. 

Jabberd  runs  from  the  compilation  directory.  Jabberd  is  compiled  locally 
in  /usr/local/ j  abberd-1 .4.2  and  all  the  executables  are  in  that  directory. 

3.  Changes  to  jabber.xml 

Thejabber.org  page  lists  different  example  jabber.xml  pages  and  is  a  good 
resource  for  comparison,  http ://www. i abber.org/ admin/config-examples .php .  This  report 
uses  the  jabberd  daemon  1.4.2  and  not  the  experimental  jabberd  version  2.  The  following 
are  suggested  changes  to  the  j  abber  .  xml  configuration  file. 
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<!--  The  server  vCard  --> 

<vCard> 

<FN>Jabber  Server</FN> 

<DESC>A  Jabber  Server ! </DESC> 
<URL>http : / /movesinstitute . org/ </URL> 
</vCard> 


<!--  The  server  vCard  --> 

<vCard> 

<FN>xchat . Movesinstitute . org  Jabber  Server</FN> 

<DESC>xchat  MOVES  Institute  Jabber  Server ! </DESC> 

<URL>http : / / xchat .  Movesinstitute . org</URL> 

</vCard> 

Figure  47.  Changes  to  j  abber  .  xml  when  implementing  j  abberd  1.4.2. 


The  following  XML  in  j  abber  .  xml  is  the  resource  that  checks  for  updated 
versions  of  the  Jabber  server  software.  Note  that  no  functionality  is  lost  if  this  is 
commented  out.  Removing  the  <update/>  tag  is  a  good  strategy  if  the  Jabber  server  is 
behind  a  firewall.  To  use  this  feature,  change  “localhost”  to  the  hostname  or  IP  address  of 
the  server,  making  sure  that  it  is  the  same  as  the  entry  for  <host/>  above. 


<update> 

< j  abberd : cmdline  f lag="h">localhost</ j  abberd : cmdline> 

</update> 

to 

<update> 

< j  abberd : cmdline  f lag="h">xchat . movesinstitute . org</j  abberd: cmdline> 
</update> 

Figure  48.  Changes  to  j  abber  .  xml  needed  to  implement  version  updates  in 
j  abberd. 


The  following  XML  in  j  abber  .  xml  is  the  default  server  record-logging 
component,  which  logs  general  statistical  and  tracking  data.  This  code  stores  the  log  file 
in  XML  format. 
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<log  id="rlogger"> 

<host/> 

<logtype>record</ logtype> 
<format>%d  %h  %s</format> 
<f ile>record . log</file> 
</log> 


<log  id="rlogger"> 

<host/> 

<logtype>record</ logtype> 

<format>&lt;message@time=%d  @host=%h&gt; %s&lt; /message&gt; </format> 

<f ile>record . log . xml</ f ile> 

:/log> 

Figure  49.  Changes  to  j  abber  .  xml  needed  to  implement  XML  formatted  logging 

in  j  abberd. 


An  IRC  client  is  available  at  http://www.mirc.org.  When  the  IRC  component  is 
ready,  the  following  section  shown  in  Figure  50  must  be  uncommented.  Current  efforts 
to  get  IRC  working  with  a  Jabber  server  have  been  unsuccessful  at  this  point. 

<service  id="irc"> 

<host>irc . localhost</host> 

</service> 

Figure  50.  Changes  to  j  abber  .  xml  needed  to  implement  IRC  in  j  abberd. 


The  procedure  for  connecting  xchat  to  surfaris  is  covered  by  "Splitting  Up  Jabber 
Server  Processes"  in  the  O’Reilly  book,  pp.  1 13-118.  [Monson  2001]  This  was  completed 
by  making  the  required  setting  changes  in  j  abber  .  xml  on  both  servers.  The 
connection  uses  the  default  port  for  server-to-server  connections  is  5269. 

Future  work  involves  installing  Jabberd  2.x  and  component  services.  The  2.x  beta 
was  in  not  stable,  so  the  fallback  was  the  1.4.2  release  on  surfaris  and  1.4.3  release 
on  xchat.  Open-source  component  services  for  Jabber  including  SMTP,  SMS  and 
gateways  for  AIM,  MSN,  and  Yahho  are  found  at 
http://www.iabber.org/software/components.php. 


D.  SETTING  UP  WEB  HTTP  SERVER  AND  JAVA  SERVLETS 
1.  Solutions  for  HTTP  Post 

There  are  three  ways  to  perform  an  HTTP  post  from  a  browser  to  a  Web 
server/Jabber  server:  an  HTML  form  post,  an  XML-HTTP  object,  and  an  applet.  In  the 
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HTTP  form-post  method,  the  browser  wraps  the  XML  string  into  the  value  portion  of  an 
element="value"  pair  and  posts  it  to  the  Web  server.  At  the  server  end,  the  XML 
data  is  extracted  from  the  element="value"  pair.  Extraction-code  languages  can  be 
Perl,  active  server  pages  (ASP),  Java  server  pages  (JSP)  or  Java  servlets. 

The  XML-HTTP  object  method  uses  direct  posting  of  XML  data  to  a  Jabber 
server  using  HTTP  post.  We  rejected  this  method  because  it  involves  an  ActiveX  object, 
and  is  thus  a  Windows-only  solution.  One  possibility  using  applets  is  to  incorporate 
design  time  controls  (DTCs)  from  Visual  Interdev  6.0.  [Perkins  2003] 

Using  applets  is  possible,  but  the  use  of  Java  and  Javascript  on  the  client  side  was 
undesirable  since  such  support  might  not  be  available  on  target  military  clients.  HTTP 
form  post  is  therefore  the  method  chosen. 

2.  Converting  Post  to  XML 

The  next  point  is  what  technology  is  needed  to  convert  the  post  to  XML: 
Javascript  client,  server-side  CGI  or  servlet.  This  report  uses  servlet  technology  because 
it  is  supported  on  many  different  servers  and  makes  the  smallest  program  for  the  client. 
The  steps  that  the  servlet  must  handle  are: 


• 

Client  posts  to  server. 

• 

Java  servlet  receives  from  client. 

• 

Java  servlet  processes  incoming  XHTML  Form  data  (XML  Tactical  Chat  messages). 

• 

Servlet  pulls  XML  from  post. 

• 

Servlet  sends  posts  as  a  Jabber  message  to  the  Jabber  server,  with  proper  XML 

wrapper. 

• 

The  Jabber  server  in  turn  sends  message  to  chat  room  connecting  other  clients 

(Exodus,  Rhymbox  or  BuddySpace). 

Figure  5 1 .  Functions  performed  by  the  Post  to  XML  servlet. 


3.  Jabber  Parameter  Names 

Jabber  uses  specific  parameters  that  must  be  set  in  the  web  .  xml  file.  Figure  52 
lists  those  parameters  and  gives  a  brief  description. 
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Param-name 

Param-name 

Description 

fromName 

B9j2@dickdale.cs.nps.navy.mil 

Sender  account  name.  One  entry  only. 

fromPassword 

<password> 

Password  of  sender. 

One  entry  only. 

toName 

lee@dickdale.cs.nps.navy.mil, 

brutzman@dickdale.cs.nps.navy.mil 

Who  to  send  to. 

Multiple  entries  delimited  by  commas. 
Spaces  are  automatically  trimmed. 

toBody 

This  is  a  sample  JABBER  message 
from  a  Java  Servlet 

Default  message  body  if  none  is 
provided. 

weblogDir 

weblog 

Directory  to  save  generated  XML 
messages. 

Figure  52.  Required  parameters  for  Jabber  to  be  set  in  the  web  .  xml  file. 


4.  Web  Server  Configuration  -  web .  xml 

The  web .  xml  file  tells  the  servlet  what  parameters  to  expect  from  the  XHTML 
form.  Below  is  the  web .  xml  file  with  the  toName  parameter  highlighted  to  show  the 
format  for  a  JID. 
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<?xml  version="l . 0"  encoding="UTF-8 " ?> 

< ! DOCTYPE  web-app  PUBLIC  "-//Sun  Microsystems,  Inc. //DTD  Web  Application 
2 . 3//EN"  "http: / / java . sun . com/dtd/web-app_2_3 . dtd"> 

<web-app> 

<servlet> 

<servlet-name>sendit</servlet-name> 

<servlet-class>SendIt</ servlet-class> 

<init-param> 

<param-name>f romName</param-name> 

<param-value>b9 j  2@dickdale . cs . nps . navy ,mil</param-value> 
</init-param> 

<init-param> 

<param-name>f romPassword</param-name> 

<par am- value >l</param- value > 


<param-value>This  is  a  sample  JABBER  message  from  a  Java 
Servlet</param-value> 

</init-param> 

<init-param> 

<param-name>weblogDir</param-name> 

<param-value>weblog</param-value> 

</init-param> 

</servlet> 

<servlet-mapping> 

< servlet- name >sendit</servlet-name> 

<url-pattern>/ sendit</url-pattern> 

</ servlet-mapping> 

</web-app> 

Figure  53.  The  web  .  xml  configuration  file  that  configures  the  XTC  servlet. 

5.  Web  Server  Configuration  -  server.xml 

This  report  uses  Tomcat  as  the  Web  server.  To  enable  logging  on,  the  following 
update  needs  to  be  made  to  the  server.xml  file. 

<!--  darB9 J2Server  --> 

<Context  path="/XTC"  docBase="C : \Proj ect\darB9 J2Server\defaultroot"  debug="0" 
reloadable="true"> 

<Logger  className="org . apache . catalina . logger . FileLogger " 
pref ix=" localhost_darB9 J2Server_log . "  suf f ix=" . txt "  timestamp=" true" /> 
</Context> 

Figure  54.  Changes  to  the  server.xml  file  that  enable  log-on  the  Tomcat  server. 
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6.  Servlet  Configuration:  Peer  to  Peer 

The  following  Java  servlet  is  needed  to  send  a  Jabber  message  through  the  Web 
server  to  a  Jabber  server. 


// - 

j  k  k 

k 

*  @param  accountName  login  user  name  (e.g.  myaccount) 

*  @param  serverName  login  server  (e.g.  dickdale.cs.nps.navy.mil) 

*  @param  password  login  user  password 

*  @param  toAccount  which  account  to  send  to  (e.g.  anotheraccount ) 

*  @param  toServer  which  server  (e.g.  dickdale.cs.nps.navy.mil) 

*  @param  messageBody  body 

*  ^return  success=true,  failure=false 
*/ 

public  String  sendMsgP2P (String  accountName,  String  serverName,  String 

password.  String  toAccount,  String  toServer,  String  messageBody)  { 
//  Setup  a  connection  bean. 


// - 

//  Send  the  message 

MessageBuilder  mb=new  MessageBuilder () ; 

Message  msg; 

//  Who  and  where  to  send  the  message  to. 

mb . setToAddress (new  JID (toAccount,  toServer,  null)); 

mb . setSub j ect (  MSG_SUBJECT_P2P  +"  "+  SystemUtil . getDateTimel4 ( )  ); 

mb. setBody (messageBody) ; 

try  { 

msg= (Message) mb .build ( )  ; 

} 

catch  ( InstantiationException  e)  { 

//  If  the  build  failed... 

} 

//Send  the  message! 
cb . send (msg) ; 
return  "GOOD"; 

}  /*  sendMsgP2P  */ 

Figure  55.  Servlet  source  code  that  enables  a  message  to  be  sent  P2P. 


74 


7.  Servlet  Configuration  -  Chat  room 

The  following  Java  servlet  sends  a  Jabber  message  through  the  Web  server  to  a 
chat  room  on  a  Jabber  server. 


// - 

j  -k  -k 

*  send  JABBER  message  to  chatroom 

~k 

*  @param  accountName  login  user  name  (e.g.  myaccount) 

*  @param  serverName  login  server  (e.g.  dickdale.cs.nps.navy.mil) 

*  @param  password  login  user  password 

*  @param  nickName  nick  name  to  use  in  chatroom 

*  @param  toAccount  which  account  to  send  to  (e.g.  anotheraccount ) 

*  @param  toServer  which  server  (e.g.  dickdale.cs.nps.navy.mil) 

*  @param  messageBody  body 

*  ^return  success=true,  failure=false 
*/ 

public  String  sendMsgChatRoom (String  accountName,  String  serverName,  String 
password.  String  nickName,  String  toAccount,  String  toServer,  String 
messageBody)  { 

//  Setup  a  connection  bean. 


// - 

//  Send  Presence 

sendPresence (cb,  new  JID (toAccount,  toServer,  nickName),  null, 
"available",  "available"); 

//Add  the  room  address  to  the  list 
PresenceBean  pbean  =  new  PresenceBean  () ; 
pbean . setConnBean (cb) ; 

// - 

//  Send  to  Group  Chat 

GroupChatBean  gcb  =  new  GroupChatBean  (cb,  new  JID (toAccount,  toServer, 
nickName) ,  pbean) ; 

if  (  gcb. sendMessage (null,  messageBody)  )  { 

gcb . shutdown ( ) ; 
return  "SUCCESS"; 

} 

else  { 

gcb . shutdown ( ) ; 
return  "FAILED"; 

} 

}  /*  sendMsgChatRoom  */ 

Figure  56.  Servlet  source  code  that  enables  a  message  to  be  sent  to  a  chat  room. 


E.  SUMMARY 

This  chapter  defines  the  capabilities  of  the  clients,  servers,  and  XHTML  needed  to 
demonstrate  a  successful  XML-based.  Jabber  tactical-chat  system.  It  describes  how  to 
download,  configure  and  install  an  off-the-shelf  Jabber  client  and  shows  two  installations 
of  a  jabberd  server.  Finally,  this  chapter  shows  how  to  configure  a  Web  server  to  handle 
XHTML-to-Jabber  servlets. 
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VII.  EXAMPLE  XTC  APPLICATION  USING 
JABBER  PROTOCOLS 


A.  INTRODUCTION 

This  chapter  describes  the  development  approach  used  to  design  an  XML-based, 
Jabber-enabled,  tactical-chat  system.  The  first  section  discusses  the  fundamental  use  of 
XML,  XHTML,  and  open-source  software  in  this  report.  Next  is  a  list  of  initial  target 
capabilities  for  XTC,  followed  by  an  explanation  of  system  design.  Details  about  the 
XHTML  forms  and  XML  behind  XTC  are  then  given,  followed  by  an  outlined  tactical 
scenario  and  suggestion  regarding  how  XTC  can  be  used.  The  chapter  then  examines 
policy  issues  and  related  administrative  developments  with  XTC  and  Jabber. 


B.  FUNDAMENTAL  TECHNOLOGIES  AND  DEVELOPMENT 

METHODOLOGY 

This  section  describes  the  specific  technologies  and  development  methodology 
used  to  create  XTC. 

1.  XML  Basis 

An  XML-based  tactical  chat  system  that  implements  Jabber  provides  significant 
improvements  over  the  proprietary  incompatibilities  of  currently  fielded  systems. 
Because  XML  standardizes  data,  it  can  be  extended  to  replace  and  incorporate  all 
electronic  correspondence,  including  military  messaging,  e-mail,  and  VTC  into  one 
customizable  environment.  Additionally,  the  structure  imposed  by  exclusive  use  of 
schema-governed  message  formats  provides  for  capability  extension  while  maintaining 
current  functionality. 

2.  Uses  XHTML  to  Enable  Thin  Client  Web  Page  Input 

XHTML  forms  provide  a  technology  to  predefine  the  content  of  chat  messages 
and  label  them  for  meaningful  storage  and  searching.  XHTML  offers  a  thin  client 
because  it  can  be  accessed  via  the  Web,  passing  an  XML  document  to  a  Web  server  that 
forwards  it  to  a  Jabber  server.  In  this  case,  the  Web  server  is  an  alternative  to  creating  a 
thick  client  because  it  passes  the  XML  itself.  On  the  receiving  side,  the  simplest  solution 
is  to  use  an  open-source  Jabber  client  to  read  the  XML.  Thanks  to  open-source  Jabber 
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protocols  and  a  Web-based  client,  the  system  is  easier  to  maintain  and  update  than 
current  proprietary  systems.  Future  work  might  be  to  create  a  custom  client  that  provides 
such  fdtering  and  display  options. 

3.  Uses  Open-source  Software 

The  three  approaches  to  developing  and  implementing  chat  clients  are  a 
proprietary  chat  server/client  system,  an  open-source  solution,  or  a  customization. 
Proprietary  solutions  are  too  costly  and  inflexible  for  a  technology  that  is  changing  as  fast 
as  chat.  Custom  solutions  take  long  to  develop  and  rely  on  the  developer  to  ensure 
security.  This  report  shows  the  benefits  of  using  open-source  software  to  design  a 
solution  that  is  both  flexible  and  extensible. 


C.  INITIAL  TARGET  CAPABILITIES 

This  section  describes  the  initial  capabilities  that  XTC  supports:  Jabber  client, 
Jabber  server,  and  XML  Forms.  The  Jabber  client  capabilities  are  the  features  of  the 
Jabber  client  that  are  needed  to  support  XTC,  listed  in  Figure  57. 

•  Log  into  Jabber  server 

•  Sending  a  message  from  a  client  to  a  client  -  P2P  (peer  to  peer) 

•  Sending  an  XML  chat  message  from  a  client  to  the  server  -  A2P  (application  to 
peer) 

•  View  XML  code 

•  Join  an  existing  conference  room 
Figure  57.  Jabber  client  target  capabilities. 

The  Jabber  server  capabilities  are  the  features  of  the  Jabber  server  that  are  needed 
to  support  XTC  are  listed  in  Figure  58. 

•  Support  conference  rooms 

•  Log  messages  on  the  server 

•  Send  a  message  from  one  server  to  another  server  -  A2A  (application  to 
application) 

•  Able  to  run  on  diverse  operating  systems 
Figure  58.  Jabber  server  target  capabilities. 

The  XML-forms  capabilities  are  the  features  of  the  Web  server  and  XHTML 
forms  that  are  needed  to  support  XTC  are  listed  in  Figure  59. 
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•  Display  an  XHTML  form. 

•  Submit  an  XHTML  form  to  a  Web  server. 

•  Forward  an  XML  message  from  the  Web  server  to  the  Jabber  server. 

•  Use  an  off  the  shelf  Jabber  client  to  log  into  the  server  and  view  the  message. 

•  Login/logout  to  Jabber  server  on  each  message. 

•  Add  time  stamps  -  from  Javascript  on  client  side,  obtain  “Jabber  time”  through 
call  to  server.  Use  Javascript  client  time  and  format. 

•  Allow  Jabber-wrapped  XML  tactical  message  to  be  received  by  Jabber  server; 
XML  message  appears  to  participants  in  group  session. 

Figure  59.  XML  forms  target  capabilities. 

The  capabilities  of  these  three  categories  can  also  be  displayed  working  together 
in  a  seven-step  dataflow  diagram.  The  first  two  steps  show  the  Web  server  displaying  the 
XForm  to  the  client’s  Web  browser.  Next,  the  form  posts  the  data  to  the  Web  server.  In 
steps  4  and  5,  the  Web  server  extracts  the  XML  data  and  sends  it  to  the  Jabber  server. 
Steps  6  and  7  show  the  Jabber  server  sending  the  data  to  the  Jabber  clients. 
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User  select  message  form 
of  interest. 

Complete  and  click  “Send”. 
Result  emerges  as  XML- 
based  chat  messages. 


Web  Server 


Types  Generated  from 
XML  +  XSLT 


© 

Client  Desktop 

HTML  Form 

In  browser 

I1 

Server-end 


Web  Server 


•Extract  HTML  form  data. 
•Form-up  XML  Tactical  Chat 
messages. 

>-^*Perform  validation  against 
f  ^  jchema. 


catalog  of  XTC  reports 


©S  j  I  -Connect  to  JABBER  server 
using  a  fixed 
userl  D/password. 

•Form-up  JABBER  message 
with  the  body  containing 
XTC  message. 

•Send  JABBER  messages 
as  “Peer-to-Peer”  messages 
•(provided  addressees  are 
known)  or  as  “Chatroom” 
messages 

•(provided  chatroom  name 
is  known). 

•Perform  logging. 


Jabber  Server 
JabberD 


Hosts  chat  room 


Jabber  Clients 


Exodus 


Rhymbox 


BuddySpace 


Other 


Figure  60.  This  diagram  shows  the  flow  of  data  in  the  initial  XTC  application.  The 
form  is  generated  on  the  Web  server  and  displayed  by  the  browser  to  the  client, 
who  fills  in  the  data  and  submits  it  to  the  Web  server.  The  Web  server  forwards 
the  data  to  the  Jabber  server,  which  posts  it  in  a  chat  room  where  a  client  can  read 
it. 


D.  SYSTEM  DESIGN:  INITIAL  DEMONSTRATION 

To  demonstrate  XML  chat  technology  four  distinct  steps  are  demonstrated:  Jabber 
client  login,  use  of  an  XHTML  form,  Web-server  services  and  Jabber-server 
functionality.  Figure  61  presents  the  steps  towards  completing  these  tasks: 
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1 .  Jabber  Server: 

o  Install  new  tactical  chat  jabberd  server  or  use  an  existing  one  (e.g. 
xchat.MovesInstitute.org) 

o  Receive  Jabber  messages  from  the  Web  server. 

o  Strip  Jabber  tags. 

o  Log  the  message. 

o  Put  the  message  in  the  conference  room  to  be  viewed  by  all  clients. 

2.  Jabber  Client 

o  Choose  an  off-the-shelf  Jabber  client  and  install  it.  (The  Exodus,  RhymBox, 
and  BuddySpace  clients  were  tested.) 

o  Configure  a  Jabber  client  to  connect  to  a  Jabber  server. 

o  Login  into  the  Jabber  server. 

o  Join  a  conference  room. 

3.  XHTML  Form 

o  Open  a  Web  browser  and  an  XHTML  tactical-report  fonn. 
o  Fill  out  the  XHTMF  form  and  submit  it,  using  the  Post  button. 

•  The  Javascript  embedded  in  the  Web  page  does  very  limited  validation 
of  the  data  the  user  entered. 

•  The  Javascript  sends  the  plain  text  data  (strings)  to  the  Web  server. 

4.  Web  Server: 

o  Receive  the  text  data 

o  Build  an  XMF  file  by  inserting  the  data  into  a  blank  XMF  file 

o  Validate  the  XMF  file  against  the  proper  schema 

o  Wrap  the  original  text  data  in  Jabber  tags  and  send  to  Jabber  server 
(This  causes  all  clients  to  see  only  the  text  message  without  XMF) 

OR 

Wrap  the  XMF  file  in  Jabber  tags  and  send  to  Jabber  server 

_ (This  causes  all  clients  to  see  an  XMF  file  as  text) _ 

Figure  61.  Description  of  initial  capabilities  that  XTC  demonstrates,  describing  roles 
of  Jabber  client,  XHTMF  forms,  Web  server  and  Jabber  server. 


Figure  62  shows  information  flow  during  an  XTC  session. 
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server  wraps  the  message  with  Jabber  tags  and  logs  into  the  Jabber  server  with  its 
JID,  and  sends  the  message. 


1.  Jabber  Clients 

All  the  Jabber  clients  evaluated  are  able  to  perfonn  basic  functions.  They  can  log 
into  a  Jabber  server,  send  a  message  from  client  to  client,  send  an  XML  message  from 
client  to  server,  and  view  XML  code  in  a  debugging  window. 

As  discussed  in  Chapter  V,  the  conferencing  capability  of  BuddySpace  is 
currently  not  working  as  documented. 

2.  XHTML  Forms 

XHTML  forms  are  in  the  following  message  formats  for  demonstration  purposes: 
contact  report,  position  report,  request  for  fire  report,  and  obstacle  report.  The  forms  are 
filled  in  by  the  user  and  displayed  in  the  browser  as  an  XHTML  form,  shown  in  the 
example  layout  in  Figure  63). 
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XHTML  Page 


From: 

To: 

Subj: 

Priority: 


<!--  Jabber  compatible,  or  performed  by  Jabber  wrapper  --> 
<!--  Choice  of  default,  override  --> 


Precedence: 


Classification: 


Parameter  Name  [ 
Parameter  Description 


Parameter  Name 
Parameter  Description 


Etc.  for  more  parameters 


Reset 


Post 


Cancel 


Reset 


Save 


Help 


KEY 


User  fill  in  text  box 
Page  internal  comment 
Page  displayed  text 
Buttons 


<!-  comment  --> 
Descriptive  Text 


Figure  63.  Sample  XHTML  form  layout  for  drafting  and  posting  (via  server)  to  a  chat 
channel. 


The  major  benefit  of  using  XHTML  forms  is  that  submitting  a  form  is 
independent  of  other  Jabber  clients  (P2P/A2A/A2P).  In  addition,  because  XHTML  forms 
follow  a  consistent  design  pattern,  they  can  be  auto  generated  from  a  message  schema  in 
the  future.  Figure  64  shows  the  flow  of  XML  data  from  XHTML  forms  to  the  Jabber 
Server: 


XHTML  form 

j  XSLT 

=>  XML  format  for  data 

j  HTML 

=>  POST  as  to  Web  Server 

POST  to  Web  Server  URL 

=>  Jabber  envelop  wrapping 

l  servlet,  XML 

=>  send  to  Jabber  Server 

send  to  Jabber  URL 

Figure  64.  The  flow  of  the  XML  data  from  the  XHTML  forms  to  the  Jabber  Server  in 
XTC,  showing  steps  involved  in  using  XSLT,  HTML  and  servlets  to  convert 
XHTML  form  into  Jabber  message. 
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3.  Posting  XML  to  the  Server 

The  Post,  rather  than  the  Get,  method  is  used  when  submitting  XML  to  the  Web 
server  so  as  to  get  the  maximum  length  possible.  The  goal  is  to  output  XML  to  the  Web 
server,  where  a  servlet  can  wrap  it  and  send  it  to  a  Jabber  server. 

HTML  POST  supports  "name-value"  pairs  only,  e.g.  <input  type="text" 
name="edtSubj  ect "  value="This  is  the  subject.  ">  When  the 
servlet  receives  the  HTTP  POST  request,  it  sees  "edtSubj  ect"  =  "This  is  the 
subj  ect",  where  "edtSubj  ect "  is  the  HTML  object  name,  and  "This  is  the 
subject"  is  the  HTML  object  value. 

It  is  possible  to  programmatically  create  XML  string  (element/attribute/values)  on 
the  client  Internet  browser.  To  store  the  XML  string  value,  it  needs  an  HTML  object. 

The  nonn  is  to  create  a  hidden  object  (not  visible  on  client  browser),  cinput 
type="hidden"  name="hidXMLString"  value="Where  XML  string 
should  be  .  ">  After  creation  of  XML  string,  assign  it  to  the  hidden  HTML  object. 
The  resulting  string  looks  like  this  (again  "name -value"  pair): 

"hidXMLString"="<xml>Where  XML  string  should  be.</xml>"  To 
the  servlet,  it  sees  the  "name-value"  pair.  It  searches  for  HTML  object  name  = 
"hidXMLString"  and  extracts  the  HTML  object  value. 

There  are  other  ways  to  post  XML  data  to  the  server,  e.g.,  via  a  Web-services 
approach  with  SOAP.  However,  such  techniques  are  not  currently  supported  natively  by 
the  Internet  browser  and  remain  the  subject  of  further  work. 

4.  Jabber  Server 

The  ideal  Jabber  server  is  an  off-the-shelf,  open-source  server  that  is  implemented 
without  modification.  The  Jabber  server  can  reside  on  the  same  machine  as  the  Web 
server,  but  is  not  required  to.  Jabberd  is  used  for  XTC,  providing  login,  presence, 
conference  room,  and  message-sending  capability.  Chat  messages  are  pushed  to  clients  or 
cached  until  reconnection.  Jabberd  also  provides  server-to-server  communications  and 
logging. 
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E.  TACTICAL  CHAT  MESSAGING  USER  INTERFACE 

This  section  provides  screenshots  and  a  discussion  of  the  initial  implementation  of 
an  auto-generated  XTC  message-sending  webpage  client. 

Figure  65  shows  the  XTC  form  and  description  boxes  for  the  invisible  entries  in 
the  form,  including  default  input  text  and  hidden  values. 


XML  Tactical  Chat 


Cascading  Style  Sheet  (see  <H1  >  tag  script/xtc.css) 


Header: 

Message  Type:  |blue  report 
Observer: 

Description:  - 

Size: 

Activity: 

Location: 

Unit: 

DateTime: 

Equipment:  | 

Action:  |Continuing  Mission 

Reset 


|l  BRDM 

|Conducting  Recon 
|MS289546 


r 


1 121 06  Romeo 


Displayed  in  a  HTML  <table>  using  <tr>  for  rows,  <td>  for  columns 


Attributes  such  as  "uppercase"  shall  be  defined  in 
the  XML  Schema,  if  necessary 


<input  name="tml:  Observer"  type="t{ 

»xt"  uppercase-'uppercase"  value="7> 

<input  type="hidden"  value="tml:De; 

icription"/> 

type="text"  shall  be  displayed,  type="hidden"  is  not. 

For  type-' text",  the  name,  e.g.  "tml: Observer"  is  used  when  generating 
the  XML  string. 

For  type-' hidden",  the  value  e  g.  "tml:Description"  is  used  instead. 
Therefore  there  is  an  open  tag  "tml:Description"  and  a  closing  tag 

"tml:Description" 


Microsoft  Internet  Explorer 


JL 


<?xml  version ="1.0”  encoding="UTF-8"?> 

<tml:xtc  xmlns:tml="chat.rnovei  nstltute.org/xchat" 

xmlns :  xsi ="http :// www .  w3  .org/ 200 1/XMLSchema  -  instance" 
xsi :  schema  Location = "xtcNamespace  d :  MV42 50_Adv_XML\Blue  1  .xsd"  > 
<  country = "US"  branch = "ARMY"  > 

<tml :  MessageType/  > 

<tml:Observer/> 

<tml:Description> 

<tml:Size>l  BRDM</tml:Slze> 

<tml:Acdvlty>Conductlng  Recon  </tml:  Activity > 

<tml :  Location  >  MS289546 </tml :  Location  > 

<tml:Unit/> 

<tml:DateTime>12106  Romeo  </tml:  Date  jCimei. 

<tml:  Equipment/ > 

</tml :  Description  > 


HTML  Form  data  packaged  as  XML  data 


<tml:Action>Continuing  Mission</tml:Action> 
</tml:xtc> 


Figure  65.  Shows  the  XHTML  form  and  the  types  of  XML  tags  behind  it  including 
text  and  hidden  fields. 


Figure  66  shows  the  form  data  as  it  is  submitted  to  the  Web  server. 
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Figure  66.  XHTML  Form  data  wrapped  with  Jabber  tags  and  ready  to  send  to  Jabber 
server. 

F.  TACTICAL  CHAT  MESSAGE  STRUCTURES 

This  section  shows  how  text  is  put  into  XML,  validated  by  the  schema  then  sent 

to  the  Jabber  server.  Figure  67  is  a  plain  message  as  a  text  file: 

Alpha:  Red  5 
Bravo :  1  BRDM 

Conducting  Recon 
MS289546 
191206  Romeo 

Charlie:  Continuing  Mission 

Figure  67.  Original  Text  for  a  Bluel  report  that  is  entered  into  the  XHTML  form. 
Each  type  of  report  has  its  own  blank  form.  Figure  68  is  the  Bluel  report. 
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<?xml  version="l . 0"  encoding="UTF-8 " ?> 

<xtc 

xmlns="http : / /www .movesinstitute . or g/xtc/ schemas /Tact icalMessageTemplatesl . 0 . xs 
d"  xmlns : xsi  =  "http : //www . w3 . org/2 001/XMLSchema-instance" 

xsi : schemaLocation="http : //www . movesinstitute . org/xtc/schemas/TacticalMessageTe 
mplatesl . 0 . xsd  TacticalMessageTemplatesl . 0 . xsd"> 

<TacticalMessage> 

<SpotReport> 

<head  messageType="Blue  1"  name="Spot  or  Contact  Report"  country="US" 
branch="Army"/> 

<body> 

<Observer  input="true"  label="Observer "  required="true"/> 
<Description> 

<Size  input="true"  label="Size"  required="true"/> 

<Activity  input="true"  label="Activity"  required="true"/> 
<Location  input="true"  label="Location"  required="true"/> 

<Unit  input="true"  label="Unit"  required=" false" /> 

<DateTime  input="true"  label="Time"  required="true"/> 

<Equipment  input="true"  label="Equipment"  required=" false" /> 
</Description> 

<Action  input="true"  label="Observer  Action"  required="true"/> 
</body> 

</SpotReport> 

</TacticalMessage> 

</xtc> 

Figure  68.  Blank  XML  Document  for  Bluel  Report. 


That  plain-text  data  is  typed  into  the  form  by  the  user,  which  results  in  the 
following  XML  document,  Figure  69. 

<?xml  version=" 1 . 0"  encoding="UTF-8 " ?> 

<xtc 

xmlns="http : / /www .movesinstitute . org / xtc/ schemas/TacticalMessageTemplatesl . 0 . xs 
d"  xmlns : xsi  =  "http : // www . w3 . org/2  001/XMLSchema-instance" 

xsi : schemaLocation="http : / /www . movesinstitute . org/xtc/ schemas /TacticalMessageTe 
mplatesl . 0 . xsd  TacticalMessageTemplatesl . 0 . xsd"> 

<TacticalMessage> 

<SpotReport> 

<head  messageType="Blue  1"  name="Spot  or  Contact  Report"  country="US" 
branch="Army"/> 

<body> 

<Observer>Red  5</Observer> 

<Description> 

<Size>l  BRDM</Size> 

<Activity>Conducting  Recon</Activity> 

<Location>MS28  954  6</Location> 

<Unit/> 

<DateTime>191206  Romeo</DateTime> 

<Equipment/> 

</Description> 

<Action>Continuing  Mission</Action> 

</body> 

</SpotReport> 

</TacticalMessage> 

</xtc> 

Figure  69.  Original  Message  as  an  XML  Document. 
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The  received  XML  form  inputs  are  then  validated  by  the  schema  for  that  type  of 
report.  Figure  70  is  a  section  of  the  XTC  schema  that  applies  to  the  Bluel  report.  The 
entire  schema  can  be  found  in  Appendix  D. 

<!--  Bluel  Report  Elements  (aka  Spot  Report  or  Contact  Report)  --> 

<xs: element  name="Observer "> 

<xs : complexType  mixed="true"> 

<xs : attribute  name=" input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Observer"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Size"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Size"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Activity"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Activity"/> 

<xs : attribute  name=" required"  f ixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Location"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Location"/> 

<xs : attribute  name=" required"  f ixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Unit"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Unit"/> 

<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs:element  name="DateTime"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Time"/> 

<xs : attribute  name=" required"  f ixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Equipment"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name=" input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Equipment"/> 

<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name=" Descr iption"> 

<xs : complexType> 

<xs : sequence) 

<xs: element  ref="xtc : Size"/> 

<xs : element  ref="xtc : Activity"/> 

<xs : element  re f =" xtc : Location "/> 

<xs: element  ref="xtc :Unit"/> 
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<xs : element  ref="xtc : DateTime"/> 

<xs : element  ref="xtc :Equipment"/> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

<xs: element  name=”Action"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Observer  Action"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="SpotReport"> 

<xs : complexType> 

<xs : sequence> 

<xs:element  ref="xtc : head"/> 

<xs: element  name="body"> 

<xs : complexType> 

<xs : sequence> 

<xs : element  ref="xtc : Observer "/> 

<xs : element  ref="xtc: Description "/> 

<xs:element  ref ="xtc : Action"/> 

</xs : sequence> 

</xs : complexType> 

</ xs : element> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

<!--  End  Blue  1  Elements  --> 

Figure  70.  The  Bluel  section  of  the  XTC  schema  that  validates  the  XML  Document. 
The  entire  schema  can  be  found  in  Appendix  D. 


Once  validated,  the  XML  document  is  ready  for  the  servlet  to  send  it  to  the  Jabber 
server.  Figure  71  shows  the  format  for  the  validated  Bluel  message. 

<?xml  version="l . 0"  encoding="UTF-8 " ?> 

<tml : xtc  xmlns : tml="www . xchat .movesinstitute . org/ xchat"> 

<tml: Header  country="US"  branch="Army"/> 

<tml :MessageType>Blue  l</tml :MessageType> 

<tml : Observer>Red  5</tml : Observer> 

<tml : Description> 

<tml:Size>l  BRDM</tml : Size> 

<tml : Activity>Conducting  Recon</tml :Activity> 

<tml : Location>MS2  8954  6</tml : Location> 

<tml : Unit/> 

<tml : DateTime>l 9120 6  Romeo</tml : DateTime> 

<tml : Equipment/> 

</tml : Description> 

<tml : Action>Continuing  Mission</tml : Action> 

</tml : xtc> 

Figure  7 1 .  Shows  the  original  message  after  being  validated  and  ready  for  the  servlet 

to  send  it  to  Jabber. 


The  Jabber  tags  are  then  wrapped  around  the  XML  document  and  the  message  is 
sent  to  the  Jabber  server.  Figure  72  shows  the  valid  Jabber  tags  for  a  login,  P2P,  and 
conference-room  message. 
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"Logon  to" 

<iq  id="BS  AUTH  1" 

type="set"> 

<query  xmlns=" j abber : iq : auth"> 

</ query> 

</ iq> 

<username>hello</username> 

<password>world</password> 

<resource>Surf aris</ resource> 

"Peer-to-peer"  message 


<message  to="brutzman@surfaris . cs . nps . navy .mil"  id="3"> 
<subject>Test  Subject</subject> 

<body>Test  Body</body> 

</message> 


"Conference/Chat  room"  message 


<message  to="savage@conference . xchat .movesinstitue . org"  id="8"  type="groupchat"> 
<body>Send  to  Savage  chat  room</body> 

</message> 


Figure  72.  An  example  of  valid  Jabber  tags  for  login,  peer  to  peer  (P2P)  and 
conference  room  messages. 
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Depending  on  the  message  type,  Jabbers  wrappers  are  applied.  Figures  73  and  74 
show  the  Jabber  message  format  for  P2P  and  chatroom  messages,  respectively. 

<message  xml : lang="en-us"  to=" lee@dickdale . cs . nps . navy . mil "  type="chat" 
id=" rbxl7 "> 

<x  xmlns=" rhymbox : x : j ep-0038 "> 

<name>rhymbox-l . 0</name> 

</x> 

<body>User  readable  part</body> 

<x  xmlns=" j abber : x : data"> 

<TacticalMessage> 

<SpotReport> 

<HEAD  COUNTRY="US"  BRANCH="ARMY"  MESSAGETYPE="BLUE  1"  NAME="SPOT  OR 
CONTACT  REPORT "/> 

<body> 

<Observer>SCOUT  A</Observer> 

<Description> 

<Size>23</Size> 

<Activity>RECCE</Activity> 

<Location>VR12345  67  8</Location> 

<Unit>ABl 01</Unit> 

<DateTime>12  SEP  2003</DateTime> 
<Equipment>ARTILLERY</Equipment> 

</ Descript ion> 

<Action>DETACHMENT</Action> 

</body> 

</SpotReport> 

</TacticalMessage> 

</x> 

</message> 

Figure  73.  Jabber  “message  sent”  format:  peer  to  peer. 


When  sending  to  a  conference  room,  the  wrapper  is  slightly  different. 

<message  to= " xml @ conference .surfaris.cs.nps.navy.mil"  type="groupchat "> 

<body>User  readable  part</body> 

<x  xmlns=" j abber : x : data"  type="form"> 

<TacticalMessage> 

<SpotReport> 

<HEAD  COUNTRY="US "  BRANCH="ARMY"  MESSAGETYPE="BLUE  1"  NAME="SPOT  OR 
CONTACT  REPORT "/> 

<body> 

<Observer>SCOUT  A</Observer> 

<Description> 

<Size>23</Size> 

<Activity>RECCE</Activity> 

<Location>VR12345  67  8</Location> 

<Unit>AB101</Unit> 

<DateTime>12  SEP  2003</DateTime> 
<Equipment>ARTILLERY</Equipment> 

</ Descript ion> 

<Action>DETACHMENT</Action> 

</body> 

</SpotReport> 

</TacticalMessage> 

</x> 

</message> 

Figure  74.  Jabber  “message  sent”  format:  chatroom. 
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G.  TACTICAL  DEMONSTRATION  PLAN 

The  following  scenario  demonstrates  a  notional  “call  for  fire”  report  during  an 
amphibious  assault.  There  are  three  participants:  a  commander,  an  LCAC  and  a  helo. 
They  will  be  logged  into  a  conference  room  using  off-the-shelf  Jabber  clients. 


Figure  75.  Screenshot  of  commander’s  console  as  he  creates  a  room  and  invites 
participants  to  use  XTC. 

The  LCAC  pulls  up  his  XTC  “call  for  fire”  form  and  fills  out  the  information. 

All  parties  see  the  information  at  the  same  time  in  the  chat  room. 

The  commander  reviews  the  request  and  assigns  it  to  the  helicopter. 

The  helicopter  crew  then  fires. 


H.  POLICY  ISSUES 

Firewall  policy  is  one  of  the  biggest  hurdles  when  designing  a  network  protocol. 
Figure  76  is  a  diagram  showing  the  current  policy  at  NPS,  which  is  typical  of  most  DoD 
installations.  It  shows  that  HTTP,  HTTPS,  and  SSL  ports  are  available  but  everything 
else  is  blocked. 

The  primary  policy  question  is:  Can  XML-based  Jabber  chat  be  sent  through  a 
firewall  safely? 
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The  fact  is  XML  can  already  be  passed  through  a  firewall  as  an  attachment  to  an 
e-mail,  and  Jabber  chat  is  more  secure  than  e-mail  because  chat  clients  don’t  execute 
externally  provided  code.  In  addition.  Jabber  is  set  up  so  that  servers,  not  clients,  talk  to 
each  other.  Thus  the  only  connection  needed  is  from  a  server  outside  to  a  server  inside. 

A  server-centered  S2S  approach  minimizes  the  risk  of  chat  through  a  firewall 
because: 

•  There  are  only  single  points  of  failure. 

•  It  is  not  prone  to  abuse  (for  example,  spam). 

•  Traffic  on  the  server  is  in  plain  XML  and  can  be  easily  monitored. 

The  Jabber  protocol  is  an  XML  stream  over  a  TCP  socket.  In  support  of  common 
firewall  architecture,  it  allows  standard  SOCKS  and  IP  Masquerading.  [Support  2002]. 

The  current  firewall  policies  regarding  XML-based  Jabber  at  NPS  include  the 
following  rules: 

•  http://  [port  80]  for  regular  web-server  access  is  open  for  outgoing 
requests. 

•  https://  [port  443]  for  secure  web-server  access  is  open  for  outgoing 
requests. 

•  Jabber  [port  5222]  for  Jabber  client  to  server  communication  is  blocked. 

•  Jabber  [port  5223]  for  Jabber  client  to  server  SSL  communication  is 
blocked. 

•  Jabber  [port  5269]  for  Jabber  server  to  server  communication  is  open 
between  surfaris  and  xchat  servers  only. 

When  configuring  firewall  settings,  web-server  proxy  polling  access  can  be 
considered  if  other  firewall  ports  unavailable.  Appendix  E  covers  Navy  policy.  Figure  76 
is  a  diagram  of  the  current  port  configurations  at  NPS. 
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NPS 


Figure  76.  Current  communications  diagram  and  available  ports  at  NPS.  Ports  5222 
and  5223  for  client  to  server  Jabber  communications  are  disabled  and  port  5269 
for  server  to  server  Jabber  communications  is  only  enabled  between  surfaris  and 
xchat. 

I.  RELATED  DEVELOPMENTS 

This  section  describes  the  lessons  learned  from  implementing  XTC  and  changes 
in  Jabber  that  will  directly  impact  XTC. 

1.  Lessons  Learned 

•  (Server)  To  set  up  a  conference  (chat  room)  a  separate  DNS  entry  is 
needed. 

•  (Client)  Jabber  User  Id  (JID)  is  not  the  same  as  the  nickname 
displayed  in  the  client.  I.e.,  names  are  not  eponymous.  JID  is  required 
to  send  a  Jabber  message. 
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•  (Client)  When  using  the  built  in  save  function  in  Exodus  the  chat  text 
is  saved  in  Rich  Text  Format  (RTF),  without  XML  tags. 

•  When  using  Jabber,  typical  account  names  are  of  the  form 
“username@server”  and  conference  rooms  are 
“conferenceroomname@conference. server.” 

•  User  accounts  are  automatically  added  when  connecting  and  the 
account  doesn’t  exist. 

•  Jabber  can  be  linked  to  legacy  services  (e.g.  Yahoo,  MSN,  AIM,  ICQ). 

2.  Further  Changes  In  Jabber 

Internet2,  a  consortium  of  over  200  universities  that  is  working  with  government 
and  industry  to  define  the  next-generation  Internet,  has  formed  an  instant-messaging 
workgroup  to  work  on  standardizing  on  Jabber/XMPP  technology  for  campus  and  inter¬ 
campus  IM  networks.  URL:  http://middleware.internet2.edu/i2im. 

The  replacement  to  Jabberbeans  is  as  follows: 
http://www.iabberstudio.org/proiects/b9i2/proiect/view.php 

An  alternative  open-source  chat  environment  is  Babylon  chat,  written  in  Java  with 
whiteboard  functionality  http  ://www. visops vs .  org / andy/bab ylon/ index . html. 


J.  SUMMARY 

This  chapter  shows  how  an  initial  XTC  application  was  implemented  using 
jabberd,  XHTML  forms,  servlets,  and  off-the-shelf  Jabber  clients.  It  describes  the 
fundamental  technologies  of  XML,  XHTML,  and  open-source  software,  and  how  data 
from  an  XHTML  form  is  sent  to  a  Jabber  server.  Finally,  policy  issues  and  XTC-related 
developments  are  briefly  discussed.  Future  work  includes  choosing  one  of  several 
candidate  codebases  for  establishing  an  open-source  XTC  capability. 
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VIII.  TACTICAL  CHAT  PRODUCT-LINE  ARCHITECTURE 


A.  INTRODUCTION 

This  chapter  describes  the  application  of  the  product-line  architecture  approach  to 
designing  systems  to  the  next-generation  tactical  chat  tool.  It  first  characterizes  the 
problem  of  creating  the  next  generation  chat  by  detailing  all  the  functional  requirements 
that  will  be  addressed.  Next  it  defines  the  strategic  concept  detailing  all  the  advantages 
and  disadvantages  that  tactical  chat  brings  with  it.  The  fourth  section  is  the  detailed 
architecture  followed  by  an  evaluation  of  that  architecture.  Lastly  the  high-risk  areas  of 
this  concept  are  identified  and  mitigated  where  possible. 


B.  PROBLEM  CHARACTERIZATION 

Product-line  architecture  is  a  “common  architecture  for  a  set  of  related  products  or 
systems  developed  by  an  organization.”  [Bosch  2000]  Product-line  architecture  increases 
quality,  productivity  and  time-to-market  for  software  by  focusing  on  reusable 
components.  These  advantages  can  be  gained  by  applying  the  product-line  architecture 
approach  to  XTC. 

There  are  many  ways  to  contact  an  individual  or  group  of  individuals 
electronically.  The  most  popular  methods  in  the  military  are  message  traffic,  e-mail, 
chat,  instant  messaging  (IM),  radio  and  phone.  Each  method  has  different  interfaces,  and 
although  the  same  information  is  passed,  it  must  be  recreated  in  its  specific  fonnat  and 
sent  separately.  All  of  the  methods  have  advantages,  but  when  a  user  is  required  to  use 
all  of  them  at  the  same  time  it  is  cumbersome  and  a  waste  of  time  and  effort.  This 
proposed  architecture  is  intended  to  consolidate  the  functionality  of  these  communication 
methods  into  a  single  chat  architecture. 

The  easiest  way  to  understand  this  problem  is  to  delineate  the  advantages  and 
disadvantages  of  each  method. 

Military  message  traffic  is  a  formal  way  of  passing  infonnation.  It  has  strict  rules 
and  security  which  are  necessary  in  a  military  environment  for  passing  important 
information  with  different  security  levels.  Among  other  things  it  guarantees  the  sender’s 
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identity,  proof  of  delivery,  and  content  integrity.  Messages  are  composed  and  checked 
using  a  standalone  software  package  and  manually  approved  and  entered  into  the 
messaging  system.  All  messages  are  stored  at  a  central  location  and  can  be  recalled  if 
necessary.  The  latest  version  of  the  Defense  Messaging  System  (DMS)  has  the  ability  to 
forward  messages  to  an  e-mail  client  for  reading.  The  disadvantage  of  message  traffic  is 
that  it  is  time-consuming  and  does  not  integrate  with  other  communication  systems. 

E-mail  is  less  formal  than  message  traffic  and  is  used  more  frequently  to  do  daily 
business.  It  has  many  uses  including  passing  infonnation,  tasking,  group  discussions,  and 
various  social  functions.  E-mails  are  considered  asynchronous  because  they  can  be 
composed  offline  and  both  sent  and  read  at  the  convenience  of  the  users.  This  is 
important  in  a  low-bandwidth  environment  because  real-time  connectivity  may  not  be 
available.  One  of  the  great  advantages  of  e-mail  is  the  ability  to  attach  documents/data. 
Although  this  does  create  security  concerns,  passing  large  amounts  of  preformatted 
information  rapidly  is  a  great  advantage  of  modern  communications.  The  main 
disadvantage  of  e-mail  is  that  copious  information  is  passed  to  everyone  resulting  in 
information  overload  for  the  user.  Additionally,  levels  of  security  in  e-mails,  and  there  is 
no  guarantee  that  e-mails  will  be  received  by  the  correct  user  in  a  specific  time  frame. 

Chat  is  a  multi-user  implementation  of  IM  and  is  considered  analogous.  The  main 
advantage  of  chat  is  that  it  allows  users  to  converse  in  real  time  on  multiple  subjects.  It  is 
possible  to  view  multiple  chats  at  one  time,  allowing  the  user  to  respond  and  interact  as 
necessary.  Chat  is  even  less  fonnal  than  e-mail  and  is  often  used  as  a  discussion  forum 
with  little  format  or  rules.  Chat  also  introduces  the  idea  of  presence.  This  means  that  it  is 
possible  to  identify  if  the  intended  user  is  on-line  and  receiving  the  information.  This  is  a 
significant  benefit  that  encourages  interactive  communication. 

The  main  disadvantage  of  chat  is  that,  because  of  its  lack  of  structure,  all  formal 
decisions  need  to  be  converted  manually  into  one  of  the  other  formats  for  approval. 
Additionally  traditional  chat  clients  depend  on  high  bandwidth,  and  scheduling  the 
necessary  participants  has  to  be  handled  with  another  communication  method. 

Radio  and  phone  communications  are  also  effective  real-time  communication 
methods.  Their  disadvantage  is  that  they  require  multiple  systems  that  don’t  interoperate 
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with  other  communication  systems  and  the  information  passed  is  not  easily  logged.  The 
ability  to  log  conversations  and  decisions  is  important,  especially  when  trying  to  recreate 
real-time  events  in  order  to  gain  a  better  understanding  of  the  decision-making  process. 

Other  more  passive  forms  of  electronic  communication  such  as  bulletin  boards, 
newsgroups  and  weblogs  (Blogs)  are  not  yet  commonly  used  in  military  communications. 
The  advantage  of  these  methods  is  they  incorporate  the  idea  of  subscriptions,  single 
location  storage  and  searchable  information.  The  disadvantage  is  there  is  absolutely  no 
guarantee  that  the  intended  user  is  receiving  and/or  acting  on  the  information. 

The  goal  of  the  Tactical  Chat  architecture  is  to  incorporate  the  advantages  of  the 
different  communication  methods  eliminating  duplication  of  effort  and  the  disadvantages 
of  each  method. 


C.  STRATEGIC  CONCEPT 

XML  Tactical  Chat  (XTC)  attempts  to  blur  the  line  between  different 
communication  methods,  making  the  transition  from  one  form  to  the  other  transparent  to 
the  user.  It  is  important  when  creating  the  Tactical  Chat  architecture  to  incorporate  all  of 
the  advantages  and  address  as  many  of  the  disadvantages  as  possible.  Figure  77  is  a 
consolidated  list  of  advantages  and  disadvantages  pooled  across  all  types  of  current 


communication  systems  (with  a  modest  amount  of  overlap). 


Advantages: 

Disadvantages: 

•  Asynchronous 

•  Not  integrated 

•  Attachments 

•  Duplication  of  effort 

•  Confirmation  of  delivery 

•  Inconsistent  security 

•  Consolidate  copies 

•  Information  overload 

•  Defined  rules  and  templates 

•  High  bandwidth 

•  Presence 

•  Poor  scheduling 

•  Real-time 

•  No  validation 

•  Searchable  information 

•  Secure  communications 

•  Stored  messages 

•  Subscription 

•  Support  unstructured  communications 

•  Validation  of  sender 

Figure  77.  Advantages  and  Disadvantages  of  Current  Communication  Systems. 
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The  clearest  way  to  describe  how  the  Tactical  Chat  architecture  incorporates  these 
advantages  is  with  some  use  cases.  To  realize  this  goal  some  additional  technologies  will 
be  needed  such  as  calendaring  and  contact  lists.  The  following  three  cases  describe 
sending  an  asynchronous  communication,  synchronous  communications,  and  reading 
communications.  Because  voice  conversion  software  currently  cannot  reliably  convert 
audio  to  text,  neither  radio  nor  phone  will  be  integrated  into  the  architecture  at  this  time, 
however  their  future  integration  will  be  considered  and  planned  for. 

Case  1 :  Asynchronous  communications  (E-mail  and  Messaging). 

The  user  logs  into  Tactical  Chat  using  his  or  her  single  sign-on,  chooses  a  form 
and  fills  it  out.  The  user  then  chooses  from  a  list  of  contacts  using  different  “contact 
types”  some  e-mail,  some  DMS,  and  a  Blog  site.  The  user  then  submits  his  data  which  is 
validated,  stored  and  forwarded  to  the  addressees. 

Case  2:  Synchronous  communications  (IM  and  Chat) 

The  user  logs  into  Tactical  Chat,  chooses  to  invite  some  contacts  to  a  chat, 
submitting  the  subject  and  participant  restrictions  and  roles  such  as  Administrator, 
Facilitator,  Participant  and  Reader.  The  users  are  contacted  immediately  and  their 
availability  is  displayed.  Every  user  with  Participant  level  access  or  higher  can  submit 
entries,  which  are  saved  after  each  submission.  At  the  end  of  the  “session”  any  user  can 
e-mail  the  contents  of  the  chat.  A  user  with  Administrative  access  or  higher  can  lock  the 
“session”  to  prevent  further  editing. 

Case  3:  Reading  communications 

The  user  logs  into  Tactical  Chat  using  a  single  sign-on,  chooses  to  look  at  his  or 
her  inbox.  Listed  are  the  new  and  old  messages  with  the  From,  Subject,  Date/Time,  and 
method  listed.  The  user  reads  a  message  a  few  messages  of  different  types  and  chooses 
to  schedule  a  follow-on  chat  session.  The  user  enters  the  contacts,  date/time  and  subject 
and  submits  it.  The  calendar  event  is  put  on  his/her  calendar  and  sent  to  the  other  users’ 
inboxes  for  confirmation. 

Calendaring  in  Tactical  Chat  is  different  than  the  traditional  approach.  The 
concept  is  that  a  calendar  event  is  nothing  more  than  a  subject,  Date/Time  and  user.  The 
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calendar  events  are  treated  like  other  messages  and  integrated  into  a  user’s  inbox.  This  is 
discussed  in  greater  detail  in  the  following  section. 


D.  ARCHITECTURAL  APPROACH 

The  Tactical  Chat  architecture  is  a  Blackboard  style  [Bosch  2000]  architecture 
that  passes  messages  and  user  infonnation  as  XML  fragments  for  storage  in  a  central 
database.  The  different  components  access  this  database  while  working  on  the  data  and 
submit  changes  back  to  the  database. 

1.  Framework 


The  Tactical  Chat  architecture  is  designed  to  work  within  the  existing 
communications  network.  To  do  this  it  will  require  many  standardized  interfaces,  some 
of  which  are  still  being  developed.  The  interfaces  are  divided  into  two  categories:  data 
management  and  communication.  The  data  management  interfaces  consist  of  the 
Security  and  Database  interface.  The  communications  interfaces  consist  of  the  E-mail, 
DMS,  Chat,  Blog,  Voice  to  Text,  Calendar,  Personal  Files  and  Tactical  Chat  (TC)  System 
interfaces.  Figure  78  shows  how  Tactical  Chat  connects  each  of  these  independent 
interfaces. 


Figure  78.  Candidate  XML  Tactical  Chat  (XTC)  Interfaces. 
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The  Security  Interface  enables  Tactical  Chat  to  use  the  security  features  currently 
being  developed  by  the  Navy.  Navy  Warfare  Systems  Command  is  developing  a  single 
sign-on  using  the  Security  Assertion  Markup  Language  (SAML)  technology.  [Chen 
2003]  The  specific  technique  for  implementing  the  Navy  single  sign-on  capability  is  still 
in  development,  however  the  SAML  VI.  1  Technical  architecture  (rev  03,  9  Mar  2004)  is 
available  at:  http  ://www. oasis-open,  org/committees/ download.php/ 5  83  6/sstc-saml-tech- 
overview- 1 . 1  -draft-03  .pdf. 

The  Database  Management  Interface  enables  Tactical  Chat  to  use  off-the-shelf 
databases.  This  interface  is  the  only  one  required  for  Tactical  Chat  to  work.  Tactical 
Chat  will  be  accessing  the  database  frequently  and  should  be  designed  to  handle  a  large 
volume  of  short  accesses.  The  data  passed  to  the  database  will  be  XML  fragments. 

The  Communications  Interface  needs  to  be  defined  for  each  kind  of  system  that 
needs  to  be  contacted  and  can  be  easily  modified.  E-mail  requires  a  link  to  the  Web  and 
the  ability  to  send  and  receive  mail.  DMS  requires  a  link  to  the  Defense  Message  System 
and  the  ability  to  send  and  receive  messages.  Chat  requires  a  separate  interface  for  each 
type  of  chat  used  (IRC,  MSN,  YAHOO!,  etc.).  Blog  requires  a  separate  interface  for 
each  web  site.  Voice  to  Text  requires  a  connection  to  each  voice  circuit  used.  Calendar 
events  are  typically  sent  in  e-mails.  The  Personal  Files  interface  is  used  to  upload 
attachments  and  save  messages  to  storable  media.  The  TC  Systems  interface  requires  a 
separate  interface  to  each  additional  Tactical  Chat  system. 

2.  Components 

Inside  the  “Black  Box”  of  Tactical  Chat  there  are  7  components.  Figure  79  shows 
the  interaction  between  components  and  the  Interfaces. 
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Figure  79.  XML  Tactical  Chat  (XTC)  Component  Architecture. 


Sign-In:  This  component  is  responsible  for  two  functions:  Login,  Add  New  User. 
The  Login  function  will  accept  a  unique  name,  password  and  DB  name  for  each  user. 
Once  signed  in  the  users  presence  will  be  updated  from  “Unavailable”  to  “Available.”  If 
the  Login  does  not  exist,  the  Sign-in  component  will  provide  the  function  of  Add  New 
User  which  at  a  minimum  requires  a  username,  password  and  DB  name.  The  default  DB 
name  element  is  “Local.”  Additional  DB  names  and  DB  addresses  can  be  added  to  the 
Database  component  by  the  administrator  to  allow  users  to  log  into  a  second  or  non-local 
Tactical  Chat  database.  When  a  user  is  created,  three  additional  data  elements  are 
updated;  the  creator,  the  contact  type  and  the  contact  address  which  are  explained  in  the 
Contacts  component.  When  SSO  is  available,  the  Sign-In  component  will  accept  that  as  a 
login. 

Contacts:  This  component  is  responsible  for  displaying  and  updating  a  list  of 
users  that  use  and  or  can  be  contacted  with  Tactical  Chat.  The  contacts  data  element  is  an 
XML  fragment  that  contains  zero  or  more  of  the  following  attributes:  a  single  username 
and  password,  creator,  contact  type  and  address,  presence,  and  the  standard  user 
information  (first  name,  last  name,  middle  name,  physical  address,  etc.).  Figure  80 
shows  some  sample  contacts. 
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User 

name 

Password 

Creator 

Type 

Address 

First 

Last 

Presence 

1 

JohnD 

******* 

JohnD 

Tactical 

JohnD@Tactical.mil 

John 

Doe 

Available 

2 

JaneS 

******* 

JaneS 

Tactical 

JaneS@Tactical.mil 

Jane 

Smith 

Unavailable 

E-mail 

JaneS@hotmail.com 

Chat 

JaneS@Jabber.org 

3 

NUser 

******* 

NUser 

Tactical 

NUser@Tactical.mil 

Away 

4 

global 

E-mail 

SGuy@hotmail.com 

Some 

Guy 

5 

admin 

DMS 

NPS 

NPS 

6 

JohnD 

E-mail 

OGuy  @hotmail  .com 

Other 

Guy 

7 

JohnD 

Group 

Groupl@Tactical.mil 

Group 

Mail  List 

JaneS 

Tactical 

JohnD@Tactical.mil 

Tactical 

JaneS@Tactical.mil 

E-mail 

SGuy@hotmail.com 

Tactical 

NUser@Tactical.mil 

8 

admin 

******* 

admin 

Tactical 

Admin@Tactical.mil 

Invisible 

Figure  80.  Sample  Contacts  for  XML 


actical  Chat  (XTC)  Architecture. 


The  first  column  is  a  unique  identifier  that  is  not  used  by  XML  Tactical  Chat  but 
makes  reading  the  entries  easier.  The  username  is  not  required,  but  must  be  unique  if 
used.  The  password  is  required  for  each  username  and  is  encrypted.  The  creator  by 
default  is  the  person  who  created  the  contact  element.  A  contact  element  can  only  be 
edited  by  a  user  listed  as  a  creator  or  an  admin.  Additional  creators  can  be  added. 

The  contact  type  and  address  describe  how  the  user  can  be  contacted.  The 
possible  types  are  Tactical  Chat,  Group,  E-mail,  DMS,  Chat,  Blog,  and  Voice  to  Text. 
Where  possible,  the  contact  address  is  validated  for  the  proper  fonnat  (e.g.  Type:  E-mail, 
Address:  [Name]@[Address]).  Tactical  Chat  addresses  are  generated  at  login  and  are  of 
the  format  [Username@DB  address]. 

Other  infonnation  such  as  first  name,  last  name,  middle  name,  nick  name, 
physical  address,  phone  number,  etc.  are  not  required  to  make  Tactical  Chat  work  but 
might  be  required  for  administrative  purposes.  Time  zone  is  another  element  that  can  be 
updated. 

The  last  attribute  for  a  contact  is  presence  which  shows  the  status  of  a  Tactical 
Chat  user.  The  possible  choices  are:  Available,  Unavailable,  Away,  Busy,  and  Invisible. 
When  a  user  signs  in,  the  presence  is  set  to  Available,  and  when  he  signs  out  or  closes  the 
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Tactical  Chat  application  the  presence  is  set  to  Unavailable.  The  settings  of  Busy  or 
Away  can  be  changed  by  the  user.  The  setting  of  Invisible  can  only  be  set  by  the  admin 
and  is  useful  for  automated  accounts  like  chat  hots. 

Address  books  display  two  types  of  contacts:  global  and  personal.  Registered 
users  and  official  contacts  entered  by  the  system  administrator  (creator  =  global)  appear 
in  the  global  address  book.  Entries  created  by  a  user  appear  in  their  personal  address 
book.  In  this  example  1,  2,  3,  4  would  appear  in  the  global  address  book  and  5  and  6 
would  appear  in  John’s  personal  address  book. 

A  group  contact  is  a  special  case  in  which  a  list  of  different  contact  types  and 
addresses  are  kept.  A  group  contact  will  only  appear  in  the  creator(s)  personal  address 
book  unless  an  administrator  approves  and  adds  the  global  account  creator. 

Invite:  This  component  combines  the  functions  of  creating  a  new  e-mail,  message, 
chat  session,  and  calendar  event.  These  functions  are  combined  because  they  have  the 
same  elements:  From,  To,  Date/Time,  Subject  and  Body.  Additionally  User  Roles  and 
Contact  Method,  Attachment  and  Status  elements  need  to  be  added.  Figure  81  shows 
some  example  messages. 
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ID 

Type 

From 

To 

Date/Time 

Subject 

Body 

Attach¬ 

ment 

Roles 

Status 

Method 

1 

E-mail 

JaneS 

2004-01- 

01T20:00:00 

Test 

e-mail 

Creator 

Open 

Tactical 

JohnD 

Participant 

Open 

Tactical 

2 

E-mail 

JohnD 

2004-01- 
01T21 :00:00 

Test2 

e-mail 

Pic.gif 

Creator 

Open 

Tactical 

JaneS 

Participant 

Open 

Tactical 

JaneS 

Participant 

Open 

E-mail 

3 

DMS 

JohnD 

2004-02- 
0 1 T08 :00:00 

Creator 

Restricted 

Tactical 

NPS 

Admin 

Participant 

Restricted 

DMS 

4 

Chat 

JohnD 

JohnD 

2004-02- 
0 1 T08 :00:00 

Test 

Chat 

Creator 

Open 

Tactical 

JaneS 

Facilitator 

Open 

Chat 

NUser 

Reader 

Open 

Tactical 

5 

Calen¬ 

dar 

JohnD 

JohnD 

2004-06- 
0 1 T  10:00:00 

Test 

Event 

Creator 

Open 

Tactical 

Figure  8 1 .  Sample  Message  Invites  for 


actical  Chat  Architecture. 


The  first  column  is  a  message  identifier  that  is  used  by  Tactical  Chat  to  identify 
messages  that  are  linked  like  a  chat  or  series  of  e-mails.  The  Type  element  is  an  optional 
setting  used  to  describe  what  kind  of  message  is  being  sent  and  useful  when  sorting 
messages.  Possible  choices  are  Tactical,  E-mail,  DMS,  Fonn,  Chat,  Blog,  Calendar  or 
Voice.  If  DMS  or  Form  is  selected  then  no  body  should  be  filled  in  because  the 
Compose/Read  Component  will  be  activated. 

The  From  element  is  entered  automatically  using  the  creator  of  the  message  user 
name.  The  To  element  can  be  selected  from  the  list  of  contacts  or  entered  by  the  user. 

The  Date/Time  attribute  will  use  Universal  time  (Zulu)  and  conform  to  ISO  8601  which 
is  YYYY-MM-DDThh:mm:ss  [ISO  2003]  where  the  time  zone  T  is  used  to  separate  the 
date  and  time  components.  The  default  date/time  will  be  supplied  by  database  however  it 
can  be  changed  by  the  user  to  schedule  events  in  the  future. 

The  Subject  and  Body  are  entered  by  the  creator.  Attachments  are  uploaded  to 
the  Tactical  Chat  by  the  Input/Output  element  and  referenced  in  the  Attachment  element. 

The  Roles  element  defines  the  roles  for  a  chat  session  users.  The  possible  roles 
from  most  control  to  least  are:  Creator,  Administrator,  Facilitator,  Participant,  and 
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Reader.  The  default  role  for  the  From  element  is  Creator  and  the  To  elements  is 
Participant.  The  Creator  and  Administrator  roles  allow  the  user  to  change  any  field.  The 
Facilitator  role  is  used  in  chat  sessions  to  designate  who  is  leading  the  chat.  The 
Facilitator  can  change  the  To,  Subject,  Body,  and/or  Attachment  elements  of  the 
message.  The  Participant  role  can  add  To,  Body  or  Attachment  elements  to  the  message. 
The  Reader  role  can  only  read  the  message.  The  roles  are  explained  further  in  the 
Compose/Read  component. 

The  Status  element  has  four  settings:  Open,  Restricted,  Locked  and  Delete.  The 
default  setting  is  Open  which  allows  all  users  to  use  the  functions  assigned  in  the  Roles 
element.  The  Restricted  setting  disables  the  ability  of  users  to  add  To  elements.  The 
Locked  setting  prevents  any  changes.  Once  locked,  a  message  can  only  be  unlocked  by  a 
creator  or  administrator.  The  Delete  setting  not  only  locks  the  message  but  prevents  it 
from  being  listed  in  the  inbox.  The  Status  element  is  important  for  sending  private 
messages  and  creating  a  historical  record. 

The  last  element  of  the  Invite  component  is  the  Method  element  and  the  possible 
entries  are:  Tactical,  E-mail,  DMS,  Chat,  Blog,  Calendar  and  Voice.  All  From  element 
users  are  Tactical  and  the  default  for  To  element  users  is  Tactical  which  means  when 
submitted  the  Invite  will  be  stored  in  the  database.  If  E-mail,  DMS,  Chat,  Blog,  Calendar 
or  Voice  is  selected  then  the  In/Out  Component  will  be  activated.  The  DB  name  of  all 
Tactical  contact  will  also  be  checked.  If  the  DB  name  is  not  local  the  message  will  also 
be  forwarded  to  the  In/Out  Component. 

Sent/Inbox:  This  component  is  for  viewing  current  messages  and  calendar  events. 
The  inbox  will  get  from  the  database  all  messages  in  which  the  user  is  listed  as  a  From 
and/or  To  element.  It  can  display  any  of  the  Invite  elements  except  data,  and  at  a 
minimum  will  display  the  To,  From,  Date/Time  and  Subject.  The  option  to  delete  a 
message  is  also  available.  Messages  can  be  sorted  and/or  selected  by  any  of  the  elements 
and  displayed  in  day,  week,  and  month  views.  For  example  if  the  message  Type: 
Calendar  is  selected  and  a  week  view  is  chosen  then  all  of  the  calendar  events  for  that 
week  will  be  displayed.  When  an  individual  message  is  selected  the  Compose/Read 
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Component  will  be  executed.  This  component  will  recheck  the  database  every  second  for 
new  entries  while  the  user  is  using  this  component. 

Compose/Read:  This  component  is  used  to  compose  messages,  read  messages, 
and  participate  in  chat  session.  This  component  is  called  from  the  Contacts,  Invite  or 
Sent/Inbox  component.  It  displays  the  message  and  contacts  and  provides  space  for  a 
reply  or  chat  input.  A  reply  or  chat  input  is  stored  under  the  same  message  ID  so  when  a 
message  is  displayed  all  replies  are  displayed  with  the  user  name  and  date.  DMS  and 
Forms  can  be  displayed  in  the  form  for  editing  or  in  a  validated  text  version  for  reading. 

Database:  This  component  is  used  to  interface  Tactical  Chat  with  a  database. 

The  database  will  call  and  send  XML  fragments.  The  two  types  are  contact  and  message 
fragments.  Components  1-5  will  access  this  component.  The  default  database  will  have 
a  DB  name  of  “Local”  and  the  DB  address  will  point  to  the  local  database.  Additional 
database  can  be  added  by  the  system  administrator  to  allow  remote  login  and/or  multiple 
databases  to  be  implemented.  When  a  component  access  the  database  component  the 
users  DB  name  element  will  be  checked  and  the  corresponding  database  will  be  accessed. 

Input/Output:  This  component  is  responsible  for  sending  and  receiving  messages 
from  users  not  using  local  Tactical  Chat.  As  previously  discussed  the  formats  are  e-mail, 
chat,  DMS,  Blog,  voice  to  text,  Calendar,  TC  system.  An  XML  transformation  is  created 
for  each.  If  a  communication  to  or  from  the  Tactical  Chat  system  is  received,  the 
Communications  interface  will  execute  the  transformation  and  forward  the  message  or 
store  it  in  the  database.  For  example,  a  user  sends  an  e-mail  from  inside  and  the  data 
contains  a  From,  To,  Subject,  and  Body.  The  interface  will  take  all  of  these  data 
elements  and  send  them  in  standard  Internet  Message  Format  (RFC  2822).  [IETF  2001] 
This  component  will  check  incoming  messages  for  a  valid  username  in  the  To  element 
before  storing  the  message. 

This  component  will  also  handle  inputs  and  outputs  from  Tactical  Chat  users  with 
DB  names  not  “Local.”  Inputs  will  be  stored  to  the  database  and  outputs  will  be 
forwarded  to  the  Communications  interface  for  delivery. 
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The  Electronic  Calendar  Interface  enables  Tactical  Chat  to  use  off  the  shelf 
calendar  clients.  The  standard  for  calendaring  is  maintained  by  the  IETF,  is  called 
iCalendar  and  can  be  found  at  http://www.imc.org/ietf-calendar/index.html. 

3.  Quality  Attributes 

The  quality  attributes  of  the  Tactical  Chat  architecture  take  the  advantages  of  the 
different  electronic  communication  systems  and  describe  how  they  are  achieved.  This 
architecture  uses  a  Blackboard  style  [Bosch  2000]  and  thus  many  of  the  quality  attributes 
are  affected  by  the  pros  and  cons  of  that  style  of  architecture.  Each  quality  attribute 
contains  multiple  quality  attribute  refinements,  quality  attribute  scenarios  and  assigned 
importance  and  risk  levels.  Below  is  a  non-prioritized  list  and  description  of  the  quality 
attributes  for  Tactical  Chat. 

The  Performance  of  a  blackboard-based  system  is  generally  not  good  because  a 
lot  of  time  is  spent  searching  the  database  and  computations  are  not  optimized.  However 
high-performance  blackboard  systems  do  exist  when  the  data  fields  and  interfaces  are 
fixed.  This  fact  along  with  few  calculations  and  short  data  transfers  make  the  potential 
performance  relatively  high  for  Tactical  Chat.  The  design  of  the  database  will  greatly 
affect  the  performance  of  the  system. 

The  Maintainability  of  a  blackboard  system  is  very  high.  All  of  the  data  types  can 
be  updated  dynamically,  and  components  and  interfaces  can  be  added  and  removed 
easily.  The  volume  of  information  will  be  very  high;  however  administration  tools  that 
interface  with  the  database  can  be  easily  created  and  implemented. 

The  Reliability/ Availability  of  Tactical  Chat  has  both  pros  and  cons.  It  has  a  high 
fault  tolerance  because  data  is  stored  iteratively  and  independently  thus  the  chance  of 
corruption  is  very  low.  On  the  other  hand  because  data  entries  and  system  behavior  are 
not  specifically  monitored  making  identification  of  malfunctions  difficult. 

The  Scalability  of  Tactical  Chat  is  high.  The  number  of  users  can  be  increased  or 
decreased  as  desired.  Additional  databases  and  Tactical  Chat  systems  can  be  added  and 
removed  by  the  administrator. 
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The  Usability  of  Tactical  Chat  is  very  high.  Users  can  log-in  locally  or  remotely 
and  display  interfaces  can  be  easily  created  or  modified.  By  design  multiple  electronic 
data  types  are  combined  into  a  single  easy  to  use  interface. 

The  Security  of  Tactical  Chat  is  a  concern  because  it  uses  a  central  database  that 
can  be  accessed  by  all  components.  However  the  use  of  a  central  database  is  also 
beneficial  to  security  because  access  can  be  tightly  controlled  and  administrator  tools  can 
be  easily  implemented  to  filter  and  screen  infonnation. 

4.  Prioritized  Requirements 

All  of  the  quality  attributes  for  Tactical  Chat  have  a  high  priority  because 
electronic  communications  are  used  by  everyone,  constantly,  in  the  completion  of  daily 
business.  However,  it  is  important  to  the  design  of  the  Tactical  Chat  architecture  to 
prioritize  the  quality  attributes  to  ensure  the  design  meets  its  intended  use. 

The  most  important  quality  for  Tactical  Chat  applications  is  Usability.  As 
previously  discussed  there  are  many  communication  systems  already  available  and  an 
additional  system  that  does  not  integrate  current  uses  has  no  added  value.  If  Tactical 
Chat  is  hard  to  use  or  implement,  or  if  functionality  is  lost  then  the  chance  of  successful 
implementation  is  zero. 

The  second  most  important  attribute  is  Scalability.  The  military  tactical 
environment  includes  millions  of  users  on  many  different  networks  with  many  different 
systems  in  many  different  configurations.  The  Tactical  Chat  architecture  must  be  flexible 
enough  to  be  implemented  in  the  majority  of  these  cases  to  be  successful. 

Reliability/ Availability  is  the  next  most  important  quality  attribute.  If  a  message 
is  sent  it  needs  to  have  a  valid  sender  and  get  to  its  intended  audience  without  error. 

These  are  important  features  of  current  e-mail  and  the  DM  systems. 

The  next  quality  attribute  is  Security.  It  is  important  that  users  be  restricted  to 
only  messages  that  they  have  permission  to  read  and  that  strict  read  and  write  rules  to  the 
database  are  enforced  to  prevent  database  corruption. 
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The  fifth  quality  attribute  is  Maintainability.  The  Tactical  Chat  architecture  must 
be  easy  to  upgrade  and  administer.  Changes  internal  to  components  can’t  effect  other 
components. 

The  last  (but  still  important)  quality  attribute  is  Performance.  There  are  two 
specific  elements  of  performance  that  concern  Tactical  Chat:  bandwidth  and  speed.  The 
military  has  very  low  bandwidth  in  many  locations  and  requires  data  to  reach  its 
destination  as  fast  as  possible. 

E.  ARCHITECTURE  EVALUATION 

To  understand  how  Tactical  Chat  handles  its  quality  attributes  a  refined  attribute 
list  and  corresponding  scenarios  are  needed.  Figure  82  details  these  attributes  and  their 
relative  importance  and  risk. 
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Figure  82.  Detailed  Quality  Attributes  and  Scenarios. 


1.  Why  it’s  Good 

The  Tactical  Chat  architecture  combines  the  best  features  of  traditional  electronic 
communications  and  the  simplicity  of  using  a  single  interface.  A  Tactical  Chat  user  can 
log-in  and  read/create  e-mails,  chats,  DMS  messages,  calendar  events  and  Blog  entries. 
The  architecture  supports  both  asynchronous  and  near  real-time  communications  because 
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messages  are  stored  in  a  database  for  users  not  on-line  and  delivered  immediately  to  users 
on-line  using  the  idea  of  presence.  Tactical  Chat  supports  unstructured  messages  and 
structured  messages  using  forms  and  validation.  Storage  is  minimized  by  storing  only 
one  copy  of  each  message.  Database  calls  use  small  XML  fragments  that  are  quickly 
processed. 

Secure  communications  and  validation  of  sender  is  supported  by  user 
profiles,  user  roles  and  message  status.  Users  are  able  to  store,  search,  and  sort  messages. 
Tactical  Chat  also  supports  the  storage  of  attachments. 

The  Tactical  Chat  architecture  can  be  extended  to  support  a  large  number 
of  users,  and  connect  many  different  legacy  and  Tactical  Chat  systems  together.  Tactical 
Chat  can  also  be  extended  to  support  additional  features  such  as:  chat  bots,  machine  to 
machine,  and  machine  to  human  communications.  Filters  and  archiving  functions  can  be 
added  to  help  administration. 

Additional  functionality  such  as  whiteboarding,  subscriptions, 
confirmation  of  delivery  and  multilevel  security  are  not  included  in  the  primary 
functionality  of  Tactical  Chat  but  can  be  incorporated  with  simple  changes  to  the 
interface  components. 

2.  Vulnerabilities  and  Sensitivities 

Internally  Tactical  Chat  has  few  vulnerabilities  and  sensitivities.  There  is  strong 
user  rights  checking,  small  amounts  of  data  being  passed,  and  validation  of  message 
formats  were  possible.  The  vulnerabilities  come  from  the  interfaces  with  the  database 
and  various  communication  systems. 

There  are  two  main  vulnerabilities  of  the  Tactical  Chat  Architecture:  Scalability 
and  Security.  Scalability  is  a  vulnerability  because  with  thousands  of  messages  being 
sent  near  simultaneously  the  database  interface  needs  to  handle  a  large  amount  of 
accesses  in  a  short  amount  of  time  without  collisions.  Alternatively,  multiple  servers 
with  independent  logging  databases  can  reduse  such  bottlenecks  scalably.  Security  is  a 
vulnerability  because  there  are  many  interfaces  to  the  Tactical  Chat  including  uploading 
files  and  attachments  that  might  contain  security  holes  or  viruses. 
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A  third  sensitivity  is  Performance.  Performance  is  not  a  vulnerability  internally 
because  Tactical  Chat  has  few  computations  and  assuming  the  accepted  nonnal  1-2 
second  delays  in  commercial  chat  and  e-mail,  internal  speed  is  negligible.  However, 
there  are  many  variables  that  affect  performance  externally  including  database  access 
speeds  and  communication  channel  speeds. 

F.  RISK  MANAGEMENT  STRATEGY 

The  strategy  for  managing  risk  in  the  Tactical  Chat  architecture  is  to  limit  the 
effect  vulnerabilities  can  have  and  to  monitor  their  effect  on  the  system.  The  high-risk 
elements  are  limited  to  the  three  external  interfaces:  Security,  Database  Management  and 
C  ommunications . 

The  external  security  interface  is  not  needed  for  Tactical  Chat  to  work.  Once  the 
use  of  Single  Sign-on  and  CAC  technologies  have  been  perfected  then  the  interface  can 
be  better  defined.  Until  that  point  it  is  not  recommended  that  these  technologies  be 
implemented  with  the  Tactical  Chat  architecture. 

As  described  above  the  Database  Management  interface  can  have  a  large  adverse 
effect  on  scalability  and  performance.  The  risk  management  strategy  is  to  recommend  a 
database  that  can  handle  multiple,  quick  accesses.  The  time  it  takes  to  get  data  to  and 
from  the  database  should  be  closely  monitored  and  an  administrator  warning  sent  if  the 
access  time  falls  outside  of  a  recommended  half  second  threshold.  A  simple  test  should 
be  run  against  the  database  to  detennine  the  maximum  recommended  number  of  users  to 
stay  below  the  threshold. 

The  Communication  interface  needs  to  be  closely  monitored  and  administered  for 
both  security  and  performance  reasons.  Changes  to  the  Communications  interface  are 
only  allowed  by  the  system  administrator  and  should  have  built-in  virus  checking.  The 
performance  statistics  with  other  Tactical  Chat  systems  can  be  closely  monitored  at  this 
interface.  Interfaces  should  be  given  priorities  to  optimize  performance  and  throughput. 

G.  SUMMARY 

This  chapter  discussed  a  product-line  architecture  for  developing  next-generation 
tactical  chat.  It  details  the  problem  characteristics,  strategic  concept,  architecture,  and 
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risk  management  strategy  needed  to  tackle  the  problem.  Most  importantly  it  identifies 
the  functional  requirements  and  quality  attributes  that  need  to  be  considered. 
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IX.  CONCLUSIONS  AND  FUTURE  WORK 


A.  INTRODUCTION 

This  chapter  summarizes  the  evaluated  ability  of  XTC  to  meet  all  the 
requirements  for  tactical  chat  laid  out  in  Chapter  III.  Current  success  and  failures  of  XTC 
are  first  presented  as  summary  conclusions,  followed  by  recommendations  for  future 
work  to  continue  building  up  successful  capabilities  of  XTC.  An  afterward  has  also  been 
added  to  briefly  discuss  some  of  the  major  developments  that  have  occurred  between  the 
original  work,  which  was  finished  in  March  of  2004,  and  today,  August  2007. 


B.  CONCLUSIONS 

The  following  conclusions  show  how  XTC  answers  the  questions  posed  at  the 
beginning  of  this  report. 

•  What  benefits  can  XML-based  tactical  chat  provide  to  military  communications? 

o  Flexiblity  -  can  adapt  for  the  specific  needs  of  the  military 
o  Universality  -  works  on  many  different  system 
o  Extensiblity  -  can  grow  to  incorporate  additional  features/capabilities 
o  Security  -  supports  SSL 
o  Storablity  -  All  data  is  in  XML 

•  What  are  the  tactical  requirements  for  XML-based  tactical  chat? 

XTC  met  all  the  tactical  requirements  listed  earlier,  specifically: 

o  Support  of  command  and  control,  to  include  open  dialog  as  well  as  situation 
reports,  execution  checklist  milestones  and  casualty  reports 

o  Support  of  operational  planning  at  the  micro-  and  macro  levels  for  both  future 
and  real-time  event  scheduling  and  coordination 

o  Support  of  coordination  efforts  for  administrative  support,  logistics,  technical 
support,  and  other  day-to-day  requirements 
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o  Chat-logging  so  that  valuable  information  is  preserved 
o  Ability  to  XML-ize  chat  to  facilitate  extraction  of  valuable  information 

•  What  are  the  technical  requirements  for  XML-based  tactical  chat? 

XTC  met  the  majority  of  technical  requirements,  with  a  few  pending.  The 
requirements  met  are: 

o  Mark  up  using  standardized  XML 

o  Processing  of  plain  prose,  MTF,  BGH  C2IEDM  TML,  HTML,  and  BGH 
ATTCS  reference  model  messages 

o  Message  validation  against  a  schema 

o  BGH  C2IEDM  element  compatibility  with  the  BGH  C2IEDM  architecture, 
o  Asynchronicity 
o  Client  thinness 
o  Interoperablity 
o  Firewall  policy  compatiblity 
o  Employment  of  open  source 

•  What  are  the  administrative  requirements  for  XML-based  tactical  chat? 

The  solution  used  for  XTC  was  off  the  shelf  and  not  customized.  The 
administrative  requirements  including  defining  user  roles,  user  permissions,  scheduling, 
and  DITSCAP  compliance  are  not  contained  in  the  off  the  shelf  clients.  All 
administrative  requirements  are  represented  in  the  future  work  section. 

•  I  low  can  XML  be  applied  to  chat? 

The  data  from  chat  can  be  stored  in  XML  thus  easily  stored,  searched  and 
analyzed. 

•  What  is  Jabber  and  how  can  it  be  used  for  tactical  chat? 

Jabber  is  a  new,  open-source,  chat  protocol  that  enables  asynchronous  XML 
formatted  conversation.  It  is  reliable,  secure,  and  can  be  extended  and  customized 
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to  meet  tactical-chat  functionality.  It  is  more  formerly  known  as  the  Extensible 
Messaging  and  Presence  Protocol  (XMPP). 

•  What  open-source  Jabber  clients  are  available  and  how  are  they  implemented? 

We  evaluated  three  open-source  Jabber  clients:  BuddySpace,  Exodus,  and 
Rhymbox.  These  clients  are  in  different  stages  of  development  and  each  has 
desirable  features.  Because  BuddySpace  conferencing  capability  does  not 
currently  work  with  our  server,  it  cannot  be  used  with  XTC  at  this  time. 

•  Can  XML  be  sent  from  a  client  to  a  Jabber  server  and  displayed? 

By  using  the  debugging  window  on  the  Jabber  client,  the  XML  between  the 
servers  and  the  clients  can  be  viewed. 

•  Can  chat  information  be  sent  using  a  thin  client  (XHTML  page)  instead  of  thick 
( Jabber  client)? 

Y es,  it  was  demonstrate  that  XML  data  can  be  sent  from  XHTML,  validated,  sent 
to  the  Jabber  server,  and  displayed. 

•  Can  XML-based  chat  also  be  used  for  software-agent  and  combat-control 
systems  (CCS)  communications? 

Yes,  proving  that  a  servlet  can  communicate  with  the  Jabber  server  XTC  shows 
that  software-agent  communications  are  possible. 

•  How  is  a  Jabber  server  configured? 

This  question  is  expanded  because  XTC  implements  a  Web  server/Java  server 
solution.  The  Jabber  server  is  configured  using  the  jabber.xml  file,  while  the  Web 
server  is  configured  using  web. xml,  and  server.xml. 

•  What  are  the  security  benefits  and  concerns  when  using  Jabber? 

The  main  security  considerations  for  chat  code  are  reliability,  information 
assurance,  and  NMCI/IT-21  compatibility.  Code  reliability  ensures  that  the  code  is  doing 
what  it  supposed  to  and  does  not  contain  any  back  doors  or  Trojan  horses.  Information 
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assurance  guarantees  that  the  data  sent  gets  to  its  intended  recipient  and  no  one  else.  By 
meeting  NMCI  requirements  it  will  enable  the  use  of  XTC  on  Navy  networks. 


C.  RECOMMENDATIONS  FOR  FUTURE  WORK 

1.  Issues 

The  following  XML  challenges  still  need  addressing  through  further  work: 

•  How  is  XSLT  best  invoked  within  a  browser? 

•  Can  XSLT  scripts  be  composed  and  chained? 

•  Can  a  Jabber  server  be  posted  to  without  prior  registration,  perhaps  bundling  all 
info  in  a  single  post  or  including  some  framing  external  page  to  register  first? 

The  following  Jabber  questions  still  remain: 

•  How  can  Jabber  servers  be  accurately  synchronized?  One  potential  solution  is  to 
use  synchronizing  together  with  NTP  for  logging  time. 

•  What  is  the  best  way  to  log  messages  on  the  Jabber  server? 

o  A  possible  solution  that  is  the  Bandersnatch  server  plug-in  to  help  with 
logging. 

http://www.iabberstudio.org/proiects/bandersnatch/proiect/view.php 

o  Another  approach  is  to  use  the  open-source  Apache  Software  Foundation 
(ASF)  Xindice  native-XML  database  in  concert  with  the  Apache  http 
server  software. 

2.  Future  Work 

The  four  categories  of  future  work  are  client  and  server  development,  network 
optimization,  and  XTC  applications,  presented  in  Figures  83-86. 
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Recommended  Client  Development: 

•  Custom  client  or  fully  functional  HTML  interface  to  Jabber 

o  Log  on  to  Jabber  server  and  check  a  URL  for  available  message  formats 
o  Download  schema  of  reports  being  created  and  validate  on  the  client 
o  Send  validated  XML  to  the  Jabber  server 

o  Receive  XML  formatted  reports  from  the  server  and  display  them  as  text 

•  Evaluate  Web-based  Jabber  clients  like  JWChat 
https://sourceforge.net/projects/iwchat. 

•  Develop  XTC  using  a  Soap  Envelope  for  web  services  capability. 

•  Implement  dedicated  XForms  capability. 

•  Add  XSBL  binary  compression  and  forward-error  correction  (FEC)  capabilities. 

•  Auto  install 

•  Multilingual 

•  Certify  client  for  DoD  systems  with  an  SSAA. 

Figure  83.  Future  client-development  work. 
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Recommended  Server  Development: 

•  A  server  GUI  needs  to  be  researched. 

•  SSL  needs  to  be  configured  on  all  servers. 

•  Research  creating  a  gateway  from  e-mail  to  Jabber. 

•  New  server  options  (jabberd  currently  a  single  point  of  failure)  must  be  found. 

•  Implement  components  that  bridge  other  chat  clients  and  SMS. 

•  Implement  dedicated  XForms  capability. 

•  Add  XSBC  binary  compression  and  forward-error  correction  (FEC)  capabilities. 

•  Enable  user  directories 

•  Maintain  single  user  between  two  servers. 

•  Certify  server  for  DoD  systems  with  an  SSAA. 

Figure  84.  Future  server-development  work. 

Network  transport  routing  and  optimization  will  be  one  of  the  major  follow-on 
challenges  for  XTC. 

•  Payload  size  comparison  -  Jabber,  AOL,  MSN,  Yahoo,  IRC,  and  XSBC  compressed 
Jabber. 

•  Long-term  network-optimization  strategies  over  diverse  DoD  links  for  XTC 
Applications. 

•  Compare  with  Envoke  and  Lotus  Domino  system  performance. 

Figure  85.  Future  network-optimization  work. 
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The  last  area  of  work  is  applying  XTC  to  the  tactical  environment  and  designing 
the  desired  customized  usability  functions. 

•  Use  Java  access  cards  (i.e.  CAC  cards)  for  automating  watch  turnover  reports 

•  In  order  to  support  scalable  (point-to-multipoint)  audio  and  video,  the  core  XMPP 
protocol  would  have  to  be  modified  to  support  secure  data  (via  SSL)  [Boyd  2003]. 

•  Allow  MIME  types  and  URLs  to  be  accepted  and  stored. 

•  Incorporate  data  mining  support  into  the  XTC  application. 

•  Define  a  schema  for  audio,  video,  and  whiteboarding. 

•  Allow  XSLT  templates  for  available  messages  to  be  added,  deleted,  and  modified. 

•  Define  administrator,  moderator,  author,  and  participant  roles. 

•  Define  chat-room  permissions. 

•  Limit  post  content  to  relevant  information. 

•  Provide  an  interface  for  scheduling  chat. 

•  Designate  areas  of  interest  for  tactical  chat  sessions. 

Figure  86.  Future  XTC-usability  functional  work. 

D.  TRANSFORMATION  OPPORTUNITY 

Chat  is  already  changing  the  way  joint  operations  are  conducted  in  the  military. 
XML-based  tactical  chat  (XTC)  is  able  to  meet  current  chat  needs  in  a  military 
environment,  overcoming  boundaries  and  limitations  faced  by  current  chat  tools.  The 
Jabber  instant  messaging  protocols,  standards,  and  software  are  the  clear  choice  for  open 
interoperability.  If  fully  implemented,  the  extensible  nature  of  XTC  will  enable  it  to 
incorporate  various  human  and  system  communications  such  as  e-mail  and  message 
traffic,  integrating  these  with  system  information  to  potentially  reduce  user  information 
overload.  Thus  XTC  has  the  potential  to  revolutionize  tactical  communications. 

Further  work  on  this  critical  capability  is  possible  in  the  near  future,  highly 
recommended,  and  will  further  enable  the  transfonnation  of  joint  coordinated  operations. 
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E.  AFTERWORD 

The  majority  of  work  for  this  thesis  was  completed  between  the  fall  of  2003  and 
the  spring  of  2004.  Interestingly,  a  large  majority  of  the  recommendations  made  in  this 
thesis  have  come  to  pass.  It  remains  valuable  to  reflect  on  the  original  motivations, 
problems,  and  progress  when  considering  the  tactical  application  of  technical  capabilities 
which  continue  to  evolve.  In  the  time  that  has  passed  since  the  original  research  on  this 
thesis  was  completed,  some  significant  events  have  come  to  pass  regarding  the  use  of 
XMPP  chat  within  the  DoD.  Below  is  a  list  and  explanation  of  some  of  those  events: 

•  January  2004  -  “XML-Based  Tactical  Chat  (XTC):  Requirements,  Capabilities  and 
Preliminary  Progress”  technical  paper  was  published.  It  discussed  some  of  the 
original  research  and  findings  which  supported  this  thesis.  It  can  be  found  at: 
https://www.movesinstitute.org/xmsf/proiects/XTC/XmlTacticalChat2004Januarv28. 

pdf 

•  April  2005  -  Don  McGregor  was  able  to  used  XMPP  in  XML-expressed  Distributed 
Interactive  Simulation  (DIS-XML). 

•  October  2005  -  “Carrier  Strike  Group  Twelve  Sponsors  Fleet/Joint/Coalition  Testing 
of  Open  Standards  Chat  Tool.”  This  article  can  be  found  at: 

http://www.chips.navy.mil/archives/06  Jan/web  pages/XMPP.htm 

•  September  2006  -  “XML  Tactical  Chat  (XTC):  Extensible  Messaging  and  Presence 
Protocol  for  Command  and  Control  Applications”  thesis  was  completed  by  Adrian 
Armold.  It  demonstrates  the  use  of  XMPP  to  route  XML-expressed  Distributed 
Interactive  Simulation  (DIS-XML)  data  to  conduct  distributed  modeling  and 
simulation.  It  can  be  found  at:  http://theses.nps.navy.mil/06Sep  Armold.pdf 

•  August  2006  -  The  Defense  Information  Systems  Agency  (DISA)  unanimously 
approved  XMPP  for  inclusion  in  the  official  DoD  IT  Standards  Registry  (DISR)  as  a 
mandatory  standard.  It  makes  XMPP  the  only  approved  instant  messaging  standard 
approved  by  the  DISR.  http ://www.j abber. com/ CE/ ChatStandard 

Figure  87.  Major  XMPP  developments  from  January  2004  -  August  2007. 
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APPENDIX  A.  ACRONYMS 


A2A 

A2P 

AIM 

ARM 

ATCCIS 

BGH 

BGHTML 

C2IEDM 

CA 

CAC 

DAA 

DCTS 

DoD 

DIS 

DLL 

DVS 

FBE 

FNMOC 

GMU 

HTML 

HTTP 

HTTPS 

IA 

ICQ 

IM 

IRC 

IT-21 

IETF 

IWS 

JID 

JFCOM 

JSF 

LSVE 

MOE 

NCES 

NEP 

NKO 

NMCI 

NPS 

NTP 

NUWC 

ODU 


Application-to-Application 
Application-to-Peer 
America-Online  Instant  Messanger 
ATCCIS  Reference  Model 

Army  Tactical  Command  and  Control  Information  System 
Battlespace  Generic  Hub 
Battlespace  Generic  Hub  HTML 

Command  and  Control  Information  Exchange  Data  Model 

Certificate  Authorities 

Common  Access  Card 

Designated  Approving  Authority 

Defense  Collaboration  Tool  Suite 

Department  of  Defense 

Distributed  Interactive  Simulation 

Dynamic  Link  Library 

Distributed  Virtual  Simulations 

Fleet  Battle  Experiment 

Fleet  Numerical,  Meteorological,  and  Oceanographic  Center  at 
https://www.fnmoc.navy.mil 

George  Mason  University 

Hypertext  Markup  Language  at  http://www.w3.org/MarkUp 
Hypertext  Transfer  Protocol  at  http://www.w3.org/Protocols 
Secure  http 

Information  Assurance 

I  Seek  You 

Instant  Messaging 

Internet  Relay  Chat 

Information  Technology  21st  century 

Internet  Engineering  Task  Force 

Info  Work  Space 

Jabber  ID 

Joint  Forces  Command  at  http://www.jfcom.mil 

Jabber  Software  Foundation 

Large-Scale  Virtual  Environments 

Measure  of  Effectiveness 

Network  Centric  Enterprise  Services 

Navy  Enterprise  Portal  at  https://portal.tfw.navv.mil 

Navy  Knowledge  Online  at  https://wwwa.nko.navy.mil 

Navy  Marine  Corps  Intranet 

Naval  Postgraduate  School  at  http://www.nps.edu 

Network  Time  Protocol 

Naval  Undersea  Warfare  Center 

Old  Dominion  University 
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OTH 

P2P 

PGP/GPG 

PRI 

RFC 

S2S 

SAR 

SASL 

SITREP 

SMTP 

SPAWAR 

SRTP 

SSL 

TCP 

TML 

TFWeb 

TW04 

VRML  97 

UFS 

USMTF 

USJFCOM 

W3C 

XForms 

XHTML 

XML 

XMPP 

Over-the-Horizon 

Peer  to  Peer 

Pretty  Good  Privacy/Gnu  Privacy  Guard 

Portal  Request  Interface 

Request  for  Comments 

Server  to  Server 

Search  and  Rescue 

Simple  Authentication  Security  Layer 

Situation  Report 

Simple  Mail  Transfer  Protocol 

Space  and  Naval  Warfare  Systems  Command 

Selectively  Reliable  Transport  Protocol 

Secure  Sockets  Layer 

Transmission  Control  Protocol 

Tactical  Markup  Language 

Task  Force  Web 

Trident  Warrior  04 

Virtual  Reality  Modeling  Language 

User  Facing  Service 

United  States  Message  Text  Format 

United  States  Joint  Forces  Command 

World  Wide  Web  Consortium  at  http ://www. w3.org 

XML  Forms 

Extensible  Hypertext  Markup  Language 

Extensible  Markup  Language  at  http://www.w3.org/XML 
Extensible  Messaging  and  Presence  Protocol  at 
http://www.xmpp.org/ 

XMSF 

Extensible  Modeling  and  Simulation  Framework  at 
http://www.movesinstitute.org/xmsf/ 

XSL 

XSLT 

XTC 

Extensible  Stylesheet  Language 

Extensible  Stylesheet  Language  for  Transformations 
XML-based  Tactical  Chat 
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APPENDIX  B.  JABBER  CONFIGURATION  FILE  ( J ABBER.XML) 


This  is  the  Jabber  server  configuration  file.  The  file  is  broken  into  different 
sections  based  on  the  services  being  managed  by  jabberd,  the  server  daemon.  Most  of  the 
important  sections  have  comments  and  are  easy  to  modify.  Further  instructions  including 
an  annotated  version  of  this  configuration  file  and  an  installation  guide  are  found  at 
http://iabberd.iabberstudio.Org/l.4. 


<jabber> 

<!-- 

jabber. xml  for  xchat.MovesInstitute.org 
changes  : 

10  DEC  2003  brutzman  modified  rlogger  format 

—  > 

<!-- 

Note  that  when  you  see  a  tag  like  "jabberd: cmdline" ,  it's  automatically 
replaced  on  startup  with  the  command  line  flag  passed  in  to  jabberd.  This 
enables  you  to  override  parameters  set  in  this  configuration  file  if  necessary 
or  desired.  Also  note  as  you  comment  things  in  and  out  that  jabberd  does  not 
like  comments  within  comments,  so  be  careful  with  your  XML.  :) 

— > 

<!-- 

The  following  <service/>  section  is  for  the  session  manager,  the  most 
important  component  within  the  server.  This  section  contains  the  following 
types  of  information: 

*  the  server's  hostname 

*  other  basic  server  information 

*  the  location  of  the  session  log  file 

*  email  addresses  for  server  administrators 

*  registration  instructions  for  new  users 

*  a  welcome  message  for  new  users 

*  a  list  of  agents  with  which  users  can  register 

*  load  rules  for  the  modules  within  the  session  manager 
— > 

<service  id=" sessions "> 

<!- 

Replace  all  occurrences  of  "localhost"  in  this  file  by  the  hostname  of 
your  Jabber  server.  Be  aware  changing  the  server's  name  is  all  but  impossible 
once  users  start  to  use  the  server.  So  choose  a  name  that  is  permanent 
(especially  no  Intranet  hostnames  or  IP  addresses) . 

Multiple  <host/>  entries  are  allowed  -  each  one  is  for  a  separate  virtual 
server.  Note  that  each  host  entry  must  be  on  one  line,  the  server  doesn't  like 
it  otherwise!  :) 

Use  lowercase  for  the  hostname. 

—  > 

<host> 

< j  abberd: cmdline f lag="h">xchat . moves institute . org 
</ j  abberd : cmdline> 

</host> 

<!- 

This  is  the  custom  configuration  section  for  the  Jabber  session  manager, 

a.k.a.  " JSM" . 

— > 

< j  sm  xmlns  =  " j  abber : conf ig : j  sm"> 

<!  — 
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The  <filter/>  section  below  determines  settings  for  mod_filter,  a  server- 
side  module  built  into  JSM  that  enables  users  to  set  delivery  rules  for 
messages  they  receive  (not  yet  supported  by  all  clients).  The  <allow/> 
subsection  specifies  which  conditions  and  actions  to  enable.  High-level 
descriptions  of  each  setting  can  be  found  below: 

*  <default/>  -  a  user  cannot  delete  this  one,  it's  the  default  rule  for 
delivering  messages 

*  <max  size/>  -  the  maximum  number  of  rules  in  a  user's  rule  set  (we 
don't  want  to  overdo  it!) 

*  conditions . . . 

*  <ns/>  -  matches  the  query  xmlns  attrib  on  an  iq  packet 

*  <unavailable/>  -  matches  when  user  is  unavailable 

*  <from/>  -  matches  the  sender  of  the  message 

*  <resource/>  -  matches  the  receiver's  resource 

*  <subject/>  -  matches  the  subject  of  the  message 

*  <body/>  -  matches  the  body  of  the  message 

*  <show/>  -  matches  the  show  tag  on  the  receiver's  presence 

*  <type/>  -  matches  the  type  of  the  message 

*  <roster/>  -  matches  if  the  sender  is  in  your  roster 

*  <group/>  -  matches  if  the  sender  is  in  the  specified  group 

*  actions  .  .  . 

*  <error/>  -  replies  with  an  error 

*  <offline/>  -  stores  the  messages  offline 

*  <forward/>  -  forwards  the  message  to  another  jid 

*  <reply/>  -  sends  a  reply  to  the  sender  of  the  message 

*  <continue/>  -  continues  processing  of  the  rules 

*  <settype/>  -  changes  the  type  of  the  message 
— > 


the 


<filter> 

<default/> 

<max_size>100</max_size> 

<allow> 

<conditions> 

<ns/> 

<!--  Matches  if  the  iq's  xmlns  is  the  same  as  the  specified  namespace  --> 

<unavai table /> 

<!--  Flag  that  matches  when  the  reciever  is  unavailable  (offline)  --> 

<f rom/> 

<!--  Matches  if  the  sender's  jid  is  the  specified  jid  --> 

<resource/> 

<!--  Matches  if  the  sender's  resource  (anything  after  the  /  in  a  jid)  is 
specified  resource  --> 


<!--  Matches  if  the 


<subj  ect/> 

message's  subject  is  the  specified  subject 


(no  regex 


yet)  — > 

<body/> 

<!--  Matches  if  the  message  body  is  the  specified  body  (no  regex  yet)  — > 

<show/> 

<!--  Matches  if  the  receiver's  presence  has  a  show  tag  that  is  the  same 
as  the  specified  text  — > 

<type/> 

<!--  Matches  if  the  type  of  the  message  is  the  same  as  the  specified  text 
("normal"  is  okay)  --> 


<roster/> 

<!--  Flag  that  matches  when  the  sender  is  in  the  receiver's  roster  --> 

<group/> 

<!--  Matches  when  the  sender  is  in  the  specified  group  --> 

</conditions> 

<actions> 

<error/> 

<!--  Sends  back  an  error  message  to  the  sender,  with  the  specified  text  - 


-> 


<of f line/> 
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<!--  Flag  that  stores  the  message  offline  --> 

<forward/> 

<!--  forwards  the  message  to  the  specified  jid  --> 

<reply/> 

<!--  Sends  back  a  reply  to  the  sender  with  the  specified  text  in  the  body 

—  > 

<continue/> 

<!--  Flag  that  continues  rule  matching,  after  a  rule  matches  --> 

<settype/> 

<!--  Changes  the  type  of  message  to  the  specified  type,  before  delivery 
to  the  receiver  --> 

</actions> 

</allow> 

</ f ilter> 

<!--  The  server  vCard  --> 

<vCard> 

<FN>Jabber  Server</FN> 

<DESC>A  Jabber  Server ! </DESC> 

<URL>http : / / xchat .moves institute . org</URL> 

</vCard> 

<!  — 

Registration  instructions  and  required  fields.  The  notify  attribute  will 
send  the  server  administrator ( s )  a  message  after  each  valid  registration  if  the 
notify  attribute  is  present. 

— > 

<register  notif y=" yes "> 

<instructions>Choose  a  username  and  password  to 
register  with  this  server . </instructions> 

<name/> 

<email/> 

</register> 

<!  — 

A  welcome  note  that  is  sent  to  every  new  user  who  registers  with  your 
server.  Comment  it  out  to  disable  this  function. 

—  > 

<welcome> 

<subj  ect>Welcome ! </subj  ect> 

<body>Welcome  to  the  Jabber  server  at  xchat  --  we 
hope  you  enjoy  this  service!  For  information  about  how  to  use  Jabber,  visit  the 
Jabber  User's  Guide  at  http : / / j abbermanual . j abber studio . org/</body> 

</welcome> 

<!  — 

IDs  with  admin  access  -  these  people  will  receive  admin 
messages  (any  message  to="yourhostname"  is  an  admin 
message) .  These  addresses  must  be  local  ids,  they  cannot 
be  remote  addresses. 

Note  that  they  can  also  send  announcements  to  all 
users  of  the  server,  or  to  all  online  users.  To  use 
the  announcement  feature,  you  need  to  send  raw  xml  and  be 
logged  in  as  one  of  the  admin  users.  Here  is  the  syntax 
for  sending  an  announcement  to  online  users: 

<message  to= " your host name /announce/ on line"> 

<body>announcement  here</body> 

</message> 

<message  to= "your host name /announce /mo td"> 

<body>message  (of  the  day)  that  is  sent  only  once  to  all  users  that 
are  logged  in  and  additionally  to  new  ones  as  they  log  in</body> 

</message> 

Sending  to  /announce/motd/delete  will  remove  any  existing 
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motel,  and  to  /announce /motd/ update  will  only  update  the  motd 
without  re-announcing  to  all  logged  in  users. 

The  <reply>  will  be  the  message  that  is  automatically 
sent  in  response  to  any  admin  messages. 

—  > 

<!-- 

<admin> 

<read>support@localhost</read> 

<write>admin@localhost</write> 

<reply> 

<subject>Auto  Reply</subject> 

<body>This  is  a  special  administrative  address.  Your  message  was 
received  and  forwarded  to  server  administrators .</body> 

</reply> 

</admin> 

—  > 

<!-- 

This  enables  the  server  to  automatically  update  the 
user  directory  when  a  veard  is  edited.  The  update  is 
only  sent  to  the  first  listed  jud  service  below.  It  is 
safe  to  remove  this  flag  if  you  do  not  want  any  users 
automatically  added  to  the  directory. 

—  > 

<vcard2 jud/> 

<!-- 

The  <browse/>  section  identifies  the  transports  and  other 
services  that  are  available  from  this  server.  Note  that  each 
entity  identified  here  must  exist  elsewhere  or  be  further 
defined  in  its  own  <service/>  section  below.  These  services 
will  appear  in  the  user  interface  of  Jabber  clients  that 
connect  to  your  server. 

The  <browse/>  section  is  also  used  by  mod^disco  (see  below) 
for  building  the  discotitems  reply. 

—  > 

<browse> 

<!-- 

This  is  the  default  agent  for  the  master  Jabber  User 
Directory,  a.k.a.  "JUD",  which  is  located  at  jabber.org. 

You  can  add  separate  <service/>  sections  for  additional 
directories,  e.g.,  one  for  a  company  intranet. 

— > 

<service  type="jud"  j id="user s . j abber . org" 

name="Jabber  User  Directory"> 

<ns> j  abber : iq : search</ns> 

<ns> j  abber :iq:register</ns> 

</ service> 

<item  category="conference"  type="public" 
j id=" conference . xchat .moves institute .org"  name=" Public  Conferencing" 
version=" 0 . 6 . 0 "> 

<ns>http : //jabber . org/protocol/muc</ns> 
</item> 

<!  — 

The  following  services  are  examples  only,  you  will  need  to 
create/modify  them  to  get  them  working  on  your  Jabber 
server.  See  the  README  files  for  each  service  and/or  the 
server  howto  for  further  information/instructions. 

— > 

<!--  we're  commenting  these  out,  of  course  :) 

<service  type="aim"  j id="aim. localhost"  name="AIM  Transport"> 

<ns>j  abber : iq: gateway</ns> 

<ns> j  abber :iq:register</ns> 
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</service> 


<service  type="yahoo"  j id=" yahoo . localhost"  name="Yahoo!  Transport"> 
<ns> j  abber : iq: gateway</ns> 

<ns>j  abber : iq: register</ ns> 

</ service> 

end  of  <service/>  examples  --> 

</browse> 

<!-- 

"Service  Discovery"  (disco,  JEP-0030)  supersedes 
"Jabber  Browsing"  (JEP-0011) . 

The  <disco/>  section  is  used  for  building  the  disco#info  reply. 

—  > 

<disco> 

<identity  category=" services "  type=" jabber" 

name=" Jabber  1.4  Server"/> 

<feature  var=" jabber : iq:browse"/> 

< feature  var=" j  abber : iq : agents "/> 

< feature  var=" j  abber : iq : register "/> 

<feature  var=" j  abber : iq : time"/> 

<feature  var=" j abber :iq:last"/> 

<feature  var=" jabber : iq: version"/> 

</disco> 

<!  — 

Select  the  hashing  algorithm  that  mod_auth_crypt  uses 
for  storing  passwords 
Possible  values: 

crypt  ...  traditional  hashing  as  implemented  in  crypt ( ) 

SHA1  . . .  using  SHA1  hashes 
—  > 

<mo  d_au  th_c  r  y p t  > 

<hash>SHAl</hash> 

</mod_auth_crypt> 

<!-- 

Configuration  for  mod_version.  By  defining  <no_os_version/> 
mod  version  will  not  report  the  version  of  your  OS. 

—  > 

<!-- 

<mod  version> 

<no_os_version/> 

</mod_version> 

</ j  sm> 

<!-- 

The  following  section  dynamically  loads  the  individual 
modules  that  make  up  the  session  manager.  Remove  or 
comment  out  modules  to  disable  them.  Note  that  the  order 
of  modules  is  important,  since  packets  are  delivered 
based  on  the  following  order! ! 

—  > 

<load  main="jsm"> 

<j  sm>. / j  sm/ j  sm. so</ j  sm> 

<mod_echo> . / j  sm/ j  sm . so</mod_echo> 

<mod_roster> . / j  sm/ j  sm . so</mod_roster> 

<mod  time> . / j  sm/ j  sm. so</mod_time> 

<mod_vcard>. / j  sm/ j  sm. so</mod_vcard> 

<mod_last> . / j  sm/ j  sm . so</mod_last> 

<mod_version> . / j  sm/ j  sm. so</mod_version> 
<mod_announce> . / j  sm/ j  sm. so</mod_announce> 
<mod_agents> . / j  sm/ j  sm . so</mod_agents> 

<mod_browse> . / j  sm/ j  sm . so</mod_browse> 

<mod_disco>. / j  sm/ j  sm. so</mod_disco> 
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storage 


storage 


storage 


flag="s 


<mod_admin> . / j  sm/ j  sm. so</mod_admin> 

<mod_f ilter> . / j  sm/ j  sm . so</mod_f ilter> 

<mod_of fline> . / j  sm/ j  sm. so</mod_of fline> 
<mod_presence> . / j  sm/ j  sm . so</mod_presence> 

<!-- 

Authentication 

For  standard  setups  mod_auth_digest  is  recommended.  Additionally 
enable  mod_auth_plain  if  you  need  plaintext  authentication. 

For  maximum  security,  force  SSL  connections  and  use  mod  auth_crypt 
exclusively.  Be  aware  encrypted  password  storage  can  lead  to 
problems  when  migrating  to  other  authentication  mechanisms 
(LDAP. . . ) . 

Switching  from  plain/digest  to  crypt  needs  manual  work  for 

existing  accounts,  the  reverse  is  not  possible. 

http : / / j  abberd. j  abber studio . org/1 . 4/doc/ adminguide#security 

—  > 

<!--  mod_auth_digest :  Password  in  clear  text  in 

encrypted/hashed  on  the  wire  --> 

<mod_auth_digest> . / j  sm/ j  sm. so</mod_auth_digest> 
<!--  mod_auth_plain :  Password  in  clear  text  in 

and  on  the  wire.  Disable  this  if  you  do  not  use  clients 
that  need  plaintext  auth  --> 

<mod_auth_plain> . / j  sm/ j  sm . so</mod_auth_plain> 

<!--  mod_auth_crypt :  Password  encrypted/hashed  in 

clear  text  on  the  wire.  Disabled  as  this  only  makes 
sense  when  used  exclusively  and  with  SSL  mandatory 
<mod_auth_crypt> . / j  sm/ j  sm. so</mod_auth_crypt>  --> 

<mod_log> . / j  sm/ j  sm. so</mod_log> 

<mod_register> . / j  sm/ j  sm . so</mod_register> 

<mod_xml> . / j  sm/ j  sm. so</mod_xml> 

</load> 

</service> 

<!--  OK,  we've  finished  defining  the  Jabber  Session  Manager.  --> 
< !  — 

The  <xdb/>  component  handles  all  data  storage,  using  the  filesystem. 
Make  sure  the  spool  directory  defined  here  exists  and  has  proper 
permissions . 

—  > 

<xdb  id="xdb"> 

<host/> 

<load> 

<xdb_f ile> . /xdb_f ile/xdb_f ile . so</xdb_f ile> 

</load> 

<xdb_f ile  xmlns  =  " j  abber : conf ig : xdb_f ile"> 

<spool> 

< j  abberd : cmdl ine 
"> . / spool</j  abberd : cmdline> 

</spool> 

</xdb_f ile> 

</xdb> 

< !  — 

The  following  service  manages  incoming  client  socket  connections. 

There  are  several  items  you  can  set  here  to  optimize  performance: 

*  authtime  -  default  is  unlimited,  but  you  can  set  this  to 
limit  the  amount  of  time  allowed  for  authentication  to  be 
completed,  e.g.,  <authtime>10</authtime>  for  10  seconds 

*  heartbeat  -  default  is  to  not  send  out  heartbeat  packets 
to  the  clients.  This  option  allows  you  to  specify  that 


132 


you  want  heartbeats  to  happen  every  x  seconds.  This  is 
useful  if  you  have  a  lot  of  dial-up  or  laptop  users  who 
may  drop  their  connection  without  logging  off  of  jabber. 
Otherwise  the  server  won't  notice  that  they  are  offline  until 
someone  tries  to  send  a  packet  to  them  (and  the  message  is 
lost).  Example:  <heartbeat>60</heartbeat> 

*  karma  -  this  is  an  input/output  rate  limiting  system  that 
the  Jabber  team  came  up  with  to  prevent  bandwidth  hogging. 

For  details  about  karma,  read  the  io  section  at  the  bottom. 
These  are  the  low  settings  and  apply  per  connection/socket 
and  can  be  changed  as  desired. 

To  disable  rate  limiting  just  delete  the  <karma/>  section. 

—  > 

<service  id="c2s"> 

<load> 

<pthsock_client> . /pthsock/pthsock_client . so</pthsock_client> 
</load> 

<pthcsock  xmlns  =  " j  abber : conf ig : pth-csock"> 
<authtime/> 

<heartbeat/> 

<karma> 

<init>10</init> 

<max>10</max> 

<inc>l</inc> 

<dec>l</dec> 

<penalty>-6</penalty> 

<restore>10</ restore> 

</karma> 

<!-- 

Use  these  to  listen  on  particular  addresses  and/or  ports. 
Example:  <ip  port="5222">127 . 0 . 0 . l</ip> 

Default  is  to  listen  on  port  5222  on  every  interface. 

Remove  the  <ip/>  section  to  disable  non-ssl  client  connections. 
—  > 

<ip  port=" 5222 "/> 

< !  — 

The  <ssl/>  tag  acts  pretty  much  like  the  <ip/>  tag, 
except  it  defines  that  SSL  is  to  be  used  on  the 
ports  and  IP  addresses  specified.  You  must  specify 
an  IP  address  here,  or  the  connections  will  fail. 

<ssl  port=' 5223 ' >127 . 0 . 0 . l</ssl> 

<ssl  port=' 5224 ' >192.168.1 . 100</ssl> 

—  > 

</pthcsock> 

</service> 

<!-- 

This  is  the  default  server  error  logging  component, 
which  copies  to  a  file  and  to  STDERR. 

—  > 

<log  id="elogger "> 

<host/> 

<logtype/> 

<format>%d:  [%t]  (%h) :  %s</format> 

<file>error. log</file> 

<stderr/> 

</log> 

<!  — 

This  is  the  default  server  record  logging  component, 
which  logs  general  statistical/tracking  data. 

—  > 

<log  id="rlogger"> 
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<host/> 

<logtype>record</logtype> 

<format>%d:  [%t]  (%h) :  %s</format> 

<file>record. log</file> 

</log> 

<!--  The  following  two  services  are  for  handling  server-to-server 

traffic.  --> 

<!--  External  asychronous  DNS  resolver  --> 

<service  id="dnsrv"> 

<host/> 

<load> 

<dnsrv>. /dnsrv/dnsrv . so</dnsrv> 

</load> 

<dnsrv  xmlns  =  " j  abber : conf ig : dnsrv"> 

<resend  service="_xmpp-server ,_tcp">s2s</resend> 
<!--  for  supporting  XMPP  compliant  SRV  records  --> 
<resend  service="_j  abber . _tcp">s2s</resend> 

<!--  for  supporting  old  style  SRV  records  --> 
<resend>s2s</resend> 

</dnsrv> 

</service> 

<!  — 

The  following  's2s'  config  handles  server  connections  and 
dialback  hostname  verification.  The  <legacy/>  element  is 
here  to  enable  communication  with  old  1.0  servers.  The 
karma  settings  are  a  little  higher  here  to  handle  the 
higher  traffic  of  server-to-server  connections  (read 
the  io  section  below  for  more  details,  medium  settings) . 

—  > 

<service  id="s2s"> 

<load> 

<dialback> . /dialback/ dial back . so</dialback> 

</load> 

<dialback  xmlns  =  " j  abber : conf ig : dialback "> 

<legacy/> 

<!--  Use  these  to  listen  on  particular  addresses 

and/or  ports. 

<ip  port="7000"/> 

<ip  port="5269">127.0.0.1</ip> 

—  > 

<ip  port=" 52 6 9 "/> 

<ka rma> 

<init>50</init> 

<max>50</max> 

<inc>4</inc> 

<dec>l</dec> 

<penalty>-5</penalty> 

<re store>50</ re store > 

</karma> 

</dialback> 

</service> 

<!-- 

update.jabber.org  is  long  dead  but  some  clients  still 
request  update  information.  In  order  to  avoid  errors 
in  the  logs,  just  drop  packages  for  update.jabber.org. 

—  > 

<service  id="update . j  abber . org"> 

<host>update . jabber . org</host> 

<null/> 

</service> 

<!-- 

If  you  identified  additional  agents  in  the  main  <service/> 
section  (see  examples  above),  you'll  need  to  define  each 
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of  them  here  using  a  separate  <service/>  section  for  each 
<agent/>  you  identified.  Note  that  the  <agent/>  sections 
determine  what  gets  shown  to  clients  that  connect  to  your 
server,  whereas  the  following  <service/>  sections  define 
these  services  within  the  server  itself.  The  following  are 
examples  only,  you  will  need  to  create/modify  them  to  get 
them  working  on  your  Jabber  server.  See  the  README  files 
for  each  agent  and/or  the  server  howto  for  further 
information/instructions . 

—  > 

<service  id="conference . xchat .movesinstitute . org"> 

<load> 

<conf erence> . /mu-conference-0 .6.0/ src/mu- 

conference. so</conference> 

</load> 

<conference  xmlns=" j abber : config: conference"> 

<public/> 

<persistent/> 

<vCard> 

<FN>Public  Chatrooms</FN> 

<DESC>This  service  is  for  public 

chatrooms . </DESC> 

<URL>http : / / xchat .movesinstitute . org/ </URL> 
</vCard> 

<history>20</history> 

<logdir> . /logs/</logdir> 

<sadmin> 

<user>admin@localhost</user> 

</sadmin> 

<notice> 

<join>has  become  available</ join> 

<leave>has  left</leave> 

<rename>is  now  known  as</rename> 

</notice> 

</conference> 

</service> 

<!--  we're  commenting  these  out,  of  course  :) 

<service  id="aim. localhost"> 

<accept> 

<ip/> 

<port>7009</port> 

<secret> j  abber-rocks</ secret> 

</accept> 

</service> 

<service  id="yahoo . localhost"> 

<accept> 

<ip/> 

<port>9001</port> 

<secret> j  abber-rocks</secret> 

</accept> 

</service> 

end  of  <service/>  examples  --> 

<!-- 

The  following  <io/>  config  initializes  the  top-level 
I/O,  otherwise  known  as  MIO  (Managed  Input/Output) . 

—  > 

<io> 

<!--  Set  the  default  karma  for  *all*  sockets  --> 

<!--  definition  of  terms: 


135 


*  Avg.  Throughput  -  The  number  of  bytes  you  can 
send  every  second  without  incuring  any  penalty. 

*  Burst  Allowed  -  The  maximum  number  of  bytes  you 
can  send  in  2  seconds  without  incurring  any  penalty. 

*  Max  Sustained  Rate  -  If  you  send  data  as  fast  as 
you  can,  you  will  hit  penalty,  and  will  not  be 
able  to  send  for  10  seconds;  the  max  sustained 
rate  is  the  average  rate  you  can  dump  data  when 
you  are  dumping  as  much  data  as  you  can,  as  fast 
as  you  can. 

*  Seconds  to  Recover  from  Burst  -  The  amount  of  time 
it  will  take  to  reach  Avg.  Throughput  capability 
after  sending  a  max  burst  of  data. 

*  Penalty  Length  -  The  length  of  your  penalty  is 
determined  according  to  this  formula: 

abs (penalty)  *  Heartbeat  seconds 
E.g.,  a  penalty  of  -5  and  heartbeat  of  2  will 
cause  your  penalty  length  to  be  10  seconds. 

Note  that  a  penalty  CANNOT  be  less  than  -100, 
otherwise  strange  things  might  happen. 

—  > 

<!--  Example  of  Low  Karma  Limits 
Avg.  Throughput:  lk-2k/s 
Burst  Allowed  To:  5.5k/s 
Max  Sustained  Rate:  485b/s 
Seconds  to  Recover  from  Burst:  20 
Penalty  Length:  12  seconds 
<karma> 

<heartbeat>2</heartbeat> 

<init>10</init> 

<max>l 0</max> 

<inc>l</inc> 

<dec>l</dec> 

<penalty>- 6< /penal ty> 

<res tore >10</ res tore > 

</karma> 

--> 

<!--  Example  of  Medium  Karma  Limits 
Avg.  Throughput:  5k-10k/s 
Burst  Allowed:  125.5k/s 
Max  Sustained  Rate:  12.6k/s 
Seconds  to  Recover  From  Burst:  25 
Penalty  Length:  10  seconds 
<karma> 

<heartbeat>2</heartbeat> 

<init>50</init> 

<max>50</max> 

<inc>4</ inc> 

<dec>l</dec> 

<penalty>-5</penalty> 

<restore>50</restore> 

</karma> 

— > 

<!--  Example  of  High  Karma  Limits 
Avg.  Throughput:  5k-10k/s 
Burst  Allowed:  206k/s 
Max  Sustained  Rate:  34.3k/s 
Seconds  to  Recover  from  Burst:  21 
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Penalty  Length:  6  seconds 
<karma> 

<heartbeat>2</heartbeat> 

<init>64</init> 

<max>64</max> 

<inc>6</ inc> 

<dec>l</ dec> 

<penalty>-3</penalty> 

<restore>64</restore> 

</karma> 

—  > 

<!-- 

Set  rate  limits  to  monitor  the  number  of  connection 
attempts  from  a  single  IP,  any  more  than  [points] 
within  [time]  will  engage  the  limit.  This  setting 
applies  to  all  incoming  connections  to  any  service, 
unless  otherwise  overridden  by  that  service. 

—  > 

<rate  points="5"  time="25"/> 

<!-- 

The  following  section  initializes  SSL  for  top-level  I/O. 

This  works  only  when  the  server  is  compiled  with  openssl! 

Use  IPs  here  or  connections  will  fail. 

—  > 

<!-- 

<ssl> 

<key  ip= '192. 168. 1.1' >/path/ to/cert_and_key . pem</key> 

<key  ip= '192. 168. 1.100' > /path/ to /other /cert_and_key . pem</key> 
</ssl> 

—  > 

<!-- 

The  following  section  is  used  to  allow  or  deny 
communications  from  specified  IP  networks  or 
addressses.  If  there  is  no  <allow/>  section, 
then  *all*  IPs  will  be  allowed  to  connect.  If 
you  allow  one  block,  then  only  that  block  may 
connect.  Note  that  <allow/>  is  checked  before 
<deny/>,  so  if  a  specific  address  is  allowed 
but  the  network  for  that  address  is  denied, 
then  that  address  will  still  be  denied. 

—  > 

<!  — 

<allow><ip>12 7 .0.0. 0</ip><mask>255 . 255 . 255 . 0</maskx/allow> 
<allow><ip>12 . 34 . 56 . 78</ipX/ allow> 

<denyxip>22 .11.44. 0</ipXmask>255 . 255 . 255 . 0</maskx/deny> 

—  > 

</io> 

<!-- 

This  specifies  the  file  to  store  the  pid  of  the  process  in. 

—  > 

<pidfile>. /jabber ,pid</pidfile> 

</ j  abber> 
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APPENDIX  C.  XTC  EXAMPLE  TACTICAL  MESSAGE  SCHEMA 


The  following  XML  schema  was  written  by  Capt.  Brian  Hittner  USA  to  validate  example 
tactical  messages  for  XTC. 


<?xml  version="l . 0"  encoding="UTF-8 " ?> 

<xs : schema 

tar getName spa ce=" http : / /www .moves institute . org/xtc/ schema s/TacticalMessageTempl 
atesl . 0 . xsd" 

xmlns : xtc="http : / /www .movesinstitute . org/ xtc/ schemas/TacticalMessageTemplatesl . 
0 . xsd"  xmlns : xs="http : / /www . w3 . org/2001 /XML Schema" 
element FormDefault="qualified"> 

<!--  Bluel  Report  Elements  (aka  Spot  Report  or  Contact  Report)  --> 

<xs: element  name="Observer "> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Observer "/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Size"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Size"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Activity"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Activity"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Location"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Location"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Unit"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Unit"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="DateTime"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Time"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Equipment"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Equipment"/> 
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<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name=" De script ion "> 

<xs : complexType> 

<xs : sequence> 

<xs:element  ref="xtc : Size"/> 

<xs : element  ref ="xtc : Activity " /> 

<xs : element  ref="xtc : Location "/> 

<xs: element  ref="xtc : Unit"/> 

<xs : element  ref="xtc : DateTime"/> 

<xs : element  ref="xtc : Equipment"/> 

</ xs : sequence) 

</xs : complexType> 

</xs : element> 

<xs: element  name="Action"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Observer  Action"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="SpotReport"> 

<xs : complexType> 

<xs : sequence> 

<xs: element  ref="xtc : head"/> 

<xs: element  name="body"> 

<xs : complexType> 

<xs : sequence) 

<xs : element  ref="xtc : Observer "/> 

<xs : element  ref="xtc : Description"/> 

<xs: element  ref="xtc : Action"/> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

</xs : sequence) 

</xs : complexType> 

</xs : element> 

<!--  End  Blue  1  Elements  --> 

<!--  Call  For  Fire  Elements  --> 

<!--  There  would  be  an  Observer  declaration  here,  but  it  was  already  declared 
above  — > 

<xs : element  name="TargetLocation"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  f ixed="true"/> 

<xs : attribute  name="label"  f ixed="Target  Location"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="TargetDescription"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Target  Description"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="EngagementMethod"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Engagement  Method"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 
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<xs : element  name="MethodOf Fire"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Method  of  Fire"/> 

<xs : attribute  name=" required"  fixed="true"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="CallForFire"> 

<xs : complexType> 

<xs : sequence> 

<xs: element  ref="xtc : head"/> 

<xs: element  name="body"> 

<xs : complexType> 

<xs : sequence> 

<xs : element  ref="xtc : Observer "/> 

<xs : element  ref="xtc : TargetLocation"/> 

<xs : element  ref="xtc : Target Descript ion" /> 

<xs : element  ref="xtc :EngagementMethod"/> 

<xs : element  ref="xtc :MethodOfFire"/> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

<!--  End  Call  For  Fire  Elements  --> 

<!--  Blue  2a  Report  Elements  (Ammunition  Request)  --> 

<!--  There  would  be  a  Unit  declaration  here,  but  it  was  already  declared 
above  — > 

<!--  There  would  be  a  Date  Time  declaration  here,  but  it  was  already  declared 
above  --> 

<xs: element  name="HEAT105mm"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="105mm  HEAT"/> 

<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="APDS105mm"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="105mm  APDS"/> 

<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="HEAT120mm"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input' 

<xs : attribute  name=" label' 

<xs : attribute  name="required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="APDS120mm"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="120mm  APDS"/> 

<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="HEDP40mmM203Box"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="40mm  M203  HEDP,  Box"/> 


f ixed=" true " / > 
f ixed=" 12 Omm  HEAT"/> 
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<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Cal50M85Box"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed=".50  Cal  M85,  Box"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Cal50M2Boxl00"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  f ixed="true"/> 

<xs : attribute  name="label"  fixed=".50  Cal  M2,  Box  of  100"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="CoaxM607 . 62mmBox400"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed=" 7 . 62mm  M607  Coax,  Box  of  400"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="HighExplosive4 . 2in"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="4.2  in.  High  Explosive  Mortar"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="WhitePhosphorous4 . 2in"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  f ixed="true"/> 

<xs : attribute  name="label"  fixed="4.2  in.  White  Phosphorous  Mortar"/> 
<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name=" Illumination4 . 2in"> 

<xs : complexType  mixed=”true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="4.2  in.  Illumination  Mortar"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="ProximityFuze4 . 2in"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="4.2  in.  Mortar  Proximity  Fuze"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="PointDetonationFuze4 . 2in"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="4.2  in.  Mortar  Point  Detonation 

Fuze"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name=" ProximityFuze8 lmm"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  f ixed="true"/> 
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<xs : attribute  name="label"  fixed="81mm  Mortar  Proximity  Fuze"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name=" PointDetonationFuze8 lmm"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="81mm  Mortar  Point  Detonation  Fuze"/> 
<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="BlastingCapNonElectricBox"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Blasting  Cap,  Non-Electric,  Box"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="FuzeIgnitor"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  f ixed="true"/> 

<xs : attribute  name="label"  fixed="Fuze  Ignitor"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Ball5 . 56mmBox400"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed=" 5 . 56mm  Ball,  Box  of  400"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Tracer5 . 56mmBox400"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed=" 5 . 56mm  Tracer,  Box  of  400"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="FragmentationGrenade"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Grenade,  Fragmentation"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="SmokeGrenade"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Grenade,  Smoke,  High  Concentration"/> 
<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="ThermiteGrenade"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Grenade,  Thermite"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Grenade40mmHighExplosiveBox"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 
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<xs : attribute  name="label"  fixed="40mm  Grenade,  High  Explosive,  Box"/> 
<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Grenade40mmWhitePhosphorousBox"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="40mm  Grenade,  White  Phosphorous, 

Box"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Grenade4 OmmArmorPiercingBox"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="40mm  Grenade,  Armor  Piercing,  Box"/> 
<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="Ball 9mmBox50 "> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="9mm  Ball,  Box  of  50"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="LightAntitankWeaponM72 "> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="LAW,  Light  Antitank  Weapon,  M72"/> 
<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="Dragon"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Missile,  Dragon"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs: element  name="TOWIIB"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="TOW  II  B  Missile"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="StingerMissile"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed="Missile,  Stinger"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="AntiTankMine"> 

<xs : complexType  mixed=”true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Mine,  Anti-Tank"/> 

<xs : attribute  name=" required"  fixed=" false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="AntiPersonnelMine"> 

<xs : complexType  mixed="true"> 
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<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Mine,  Anti-Personnel"/> 

<xs : attribute  name="required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="ClaymoreMine"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="Mine,  Claymore"/> 

<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="HighExplosive25mmBox50"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="25mm.  High  Explosive,  Box  of  50"/> 
<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="ArmorPiercing2 5mmBox50 "> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  fixed="25mm.  Armor  Piercing,  Box  of  50"/> 
<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="HighExplosivePlasticl65mm"> 

<xs : complexType  mixed="true"> 

<xs : attribute  name="input"  fixed="true"/> 

<xs : attribute  name="label"  f ixed=" 1 65mm,  High  Explosive  Plastic"/> 

<xs : attribute  name=" required"  fixed="false"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="AmmunitionRequest"> 

<xs : complexType> 

<xs : sequence> 

<xs:element  ref="xtc : head"/> 

<xs: element  name="body"> 

<xs : complexType> 

<xs : sequence> 

<xs: element  ref="xtc :Unit"/> 

<xs : element  ref="xtc : DateTime"/> 

<xs:element  ref ="xtc : HEAT1 05mm"  minOccurs="0"/> 

<xs: element  ref="xtc :APDS105mm"  minOccurs="0"/> 

<xs:element  ref="xtc : HEAT120mm"  minOccurs="0"/> 

<xs: element  ref="xtc : APDS120mm"  minOccurs="0"/> 

<xs:element  ref ="xtc : HEDP4 0mmM203Box"  minOccurs="0"/> 
<xs:element  ref="xtc : Cal50M85Box"  minOccurs="0"/> 
<xs:element  ref ="xtc : Cal50M2Boxl00 "  minOccurs="0"/> 
<xs:element  ref ="xtc : CoaxM607 . 62mmBox4 00 "  minOccurs="0"/> 
<xs:element  ref="xtc : HighExplosive4 . 2in"  minOccurs="0"/> 
<xs: element  ref="xtc :WhitePhosphorous4 . 2in"  minOccurs="0"/> 
<xs:element  ref="xtc : I llumination4 . 2in"  minOccurs=" 0"/> 

<xs: element  ref="xtc : ProximityFuze4 . 2in"  minOccurs="0"/> 

<xs : element  ref="xtc : PointDetonationFuze4 . 2in" 


minOccurs=" 0 "/> 

minOccurs=" 0 " /> 
minOccurs=" 0 "/> 


<xs: element  ref="xtc : ProximityFuze81mm"  minOccurs="0"/> 
<xs : element  ref="xtc : PointDetonationFuze81mm" 

<xs : element  ref="xtc : BlastingCapNonElectricBox" 

<xs:element  ref="xtc : Fuzelgnitor "  minOccur s=" 0"/> 
<xs:element  ref ="xtc : Ball5 . 5 6mmBox400 "  minOccurs="0"/> 
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minOccurs=" 0 "/> 


minOccurs=" 0 "/> 


minOccurs=" 0 "/> 


minOccurs=" 0 "/> 


<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 


ref ="xtc : Tracer 5 . 5 6mmBox400 "  minOccurs=" 0 "/> 
ref="xtc : FragmentationGrenade"  minOccurs="0"/> 
ref ="xtc : SmokeGrenade"  minOccurs=" 0 "/> 
ref="xtc : ThermiteGrenade"  minOccurs=" 0"/> 
ref="xtc : Grenade40mmHighExplosiveBox" 


<xs : element  ref="xtc : Grenade40mmWhitePhosphorousBox" 


<xs : element  ref="xtc : Grenade40mmArmorPiercingBox" 


<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 
<xs : element 


ref ="xtc : Ball9mmBox50 "  minOccurs=" 0 "/> 

ref ="xtc : Light An titankWeaponM7 2 "  minOccurs=" 0 "/> 

ref="xtc : Dragon"  minOccurs="0"/> 

ref="xtc : TOWIIB"  minOccurs="0"/> 

ref="xtc : StingerMissile"  minOccurs="0"/> 

ref ="xtc : AntiTankMine"  minOccurs=" 0 "/> 

ref="xtc : AntiPersonnelMine"  minOccurs="0"/> 

ref ="xtc : ClaymoreMine"  minOccurs=" 0 "/> 

ref ="xtc : HighExplosive25mmBox50 "  minOccurs=" 0 "/> 

ref ="xtc : Armor Pier cing25mmBox50 "  minOccurs=" 0 "/> 

ref="xtc : HighExplosivePlasticl 65mm" 


</xs : sequence> 

</xs : complexType> 

</xs : element> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

<!--  End  Blue  2a  Report  Elements  (Ammunition  Request)  --> 
<!--  Tactical  Message  Elements  --> 

<xs: element  name="head"> 

<xs : complexType> 

<xs : attribute  name="messageType"  type="xs : string"/> 
<xs : attribute  name="name"  type="xs : string"/> 

<xs : attribute  name=" country"  type="xs : string"/> 

<xs : attribute  name="branch"  type="xs : string"/> 

</xs : complexType> 

</xs : element> 

<xs : element  name="TacticalMessage"> 

<xs : complexType> 

<xs : choice> 

<xs : element  ref="xtc : SpotReport"/> 

<xs : element  ref="xtc:CallForFire"/> 

<xs : element  ref ="xtc : AmmunitionRequest "/> 

</xs : choice> 

</xs : complexType> 

</xs : element> 

<!--  End  Tactical  Message  Elements  --> 

<xs: element  name="xtc"> 

<xs : complexType> 

<xs : choice  maxOccurs="unbounded"> 

<xs : element  ref="xtc : Tact icalMes sage "/> 

</xs : choice> 

</xs : complexType> 

</xs : element> 

</xs : schema> 
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APPENDIX  D.  NUWC’S  CHAT  SUPPORT  GETS  THUMBS  UP 

FROM  FLEET 


McCormack,  D.,  NUWSCOPE,  laboratory  newsletter,  May  2003,  page  3. 


NUWC?s  chat  support  gets  thumbs  up  from  Fleet 


It  all  started  with  an  overseas  communi¬ 
cation  in  October  2001  from  a  Fire 
Control  Technician  who  had  been  detailed 
to  NUWC.  He  was  now  assigned  to  a 
deployed  SSN  supporting  Operation 
Enduring  Freedom  and  had  run  into  a 
problem.  It  was  a  long  shot,  but  he  knew  if 
anyone  could  help,  it  was  the  NUWC 
engineers  who  had  the  resources  and 
corporate  knowledge  to  provide  trouble¬ 
shooting  and  technical  guidance. 

Utilizing  the  Secure  Internet  Protocol 
Network  (SIPRNet).  NUWC  contacted  the 
boat  and  provided  direct  real  time  feedback 
and  chat-room  capability.  The  problem  was 
discussed,  troubleshooting  conducted  and 
an  All  Up  Round  (AUR)  was  returned  to 
service  and  operationally  employed.  The 
theater  commander  saw  the  immediate  ben¬ 
efit  of  the  chat-room  capability.  Based  on 
this  success,  the  Submarine  Tomahawk 
Action  Board  took  the  initiative  and 
assigned  NUWC  to  develop  the  chat  capa¬ 
bility  with  all  deployed  platforms  in  theater. 

In  response  to  Type  Commander 
(TYCOM)  request  for  contingency 
planning  for  Operation  Iraqi  Freedom, 
NUWC  implemented  24/7  chat  capability 
over  the  SIPRNet  with  COMFIFTHFLT, 
COMSDCTHFLT,  COMSUBLANT  and 
COMSUBPAC.  This  capability  was  stood 
up  in  February  and  is  supported  by  all 
NUWC  technical  codes.  The  primary 
objective  is  to  rapidly  respond  to  a 
deployed  platform’s  Tomahawk  strike 
capability  issues  while  allowing  Fleet  and 
TYCOM  oversight. 

Although  bandwidth-limited,  this 
capability  provides  two-way.  real-time  text 
communications  with  deployed  platforms 
to  assist  in  strike  planning,  exercises  and 
missions,  and  to  shore  mission  planning 
activities,  and  battle  groups. 

Since  implementing  24/7  chat  capability, 
NUWC  has  monitored  and  responded  to 
deployed  platform  issues  affecting  combat 
systems,  communications,  launchers  and 
the  Tomahawk  AUR.  NUWC,  with  support 
from  other  Navy  organizations,  participated 
in  over  30  separate  chat  sessions  with  eight 
forward  deployed  platforms  to  resolve 
mechanical,  electronic,  and  mission 
planning  problems  with  the  strike  missile 


systems.  Chat  use  in  the  early  stages 
allowed  a  groom  of  the  boats  while  on 
station  and  provided  easily  accessible 
means  of  talking  through  problems. 

NUWC  chat  capability  was  also 
utilized  in  three  Babylon  Express  Fleet 
exercises,  providing  24/7  technical  support 
and  email  to  nine  boats.  These  exercises 
were  supported  with  full  operational 
manning  by  all  NUWC  subsystem  experts 
to  work  both  real  and  simulated  problems, 
allowing  NUWC.  TYCOMs,  Theater 
Commanders,  and  platforms  to  train  in  chat 
room  use  and  delivery  of  guidance  to  the 
platforms  prior  to  the  conflict. 

Recently,  COMSUBLANT  requested 
that  NUWC  implement  24/7  full  manning 
by  all  subsystem  experts  to  support  Strike 
tasking  for  Operation  Iraqi  Freedom. 
NUWC  has  provided  the  engineering 
expertise  on-line  to  assist  deployed 
platforms  in  resolving  strike  capability 
issues  rapidly.  NUWC  has  provided 
technical  concurrence  to  troubleshooting 
conducted  by  deployed  strike  platforms, 
reinforced  procedural  guidance  and 
resolved  technical  issues  that  allowed  at 
least  six  Tomahawk  AURs  to  be  placed 
back  in  ready  status  for  strike  use.  As  of 
April  4, 2003,  NUWC  has  documented  over 
45  chat  sessions  with  all  deployed 
platforms  in  the  Area  of  Region  (AOR). 

In  addition  to  direct  chat  support,  the 
Division’s  Submarine  Status  website,  http:/ 
/aimtc.nuwcnpt.navy.smil.mil,  on  the 
Advanced  Interactive  Management 
Technology  Center  (AIMTC)  SIPRNet  web 
server  was  upgraded  to  support  data 
retention  of  the  chat  support  activities. 
Tomahawk  Inventory  Reports  (TIR). 

Indigo  Firing  Reports  (IFR).  Casualty 
Reports,  and  related  GEN  ADMIN  mes¬ 
sages  received  by  the  NUWC  DMS 
Message  Center  are  automatically  pro¬ 
cessed  and  populated  in  an  AIMTC 
database  and  displayed  in  a  Tomahawk 
Scorecard  report  which  displays  aggregate 
sums  and  individual  status  of  all  the 
Tomahawks  onboard,  launched,  or  failed, 
with  dynamic  links  to  retrieve  history  data 
for  each  missile  and  the  IFRs.  In  addition 
to  the  scorecard,  a  chat  logger  service 
continuously  monitors  and  records  the 


ongoing  chat 
conversations 
which  can  be 
accessed  and 
searched  from 
the  Submarine 
Status  website. 

Chat  Summary 
Reports  are 
submitted  online 
following  each 
session  of 
NUWC  tech 
support  and  can 
be  searched  by  platform,  ship  class,  or 
keyword  from  within  the  Submarine  Status 
website  as  well.  Any  additional  supporting 
material  in  a  file  format  is  uploaded  to  the 
Submarine  Status  website  to  maximize  data 
collection  &  retention. 

Fleet  feedback  of  the  chat  capability 
has  been  tremendous.  The  following 
commentfrom  COMSUBLANT  Strike  is 
one  of  the  many  positive  ones  received: 
“Overall,  the  support  provided  by  NUWC 
in  chat  was  outstanding.  The  support  not 
only  solved  problems  but  helped  the  crews 
better  understand  various  casualties  and 
information  provided  by  the  Fire  Control 
System.  The  overall  effort  was  a  number  of 
missiles  that  were  either  returned  to 
operational  status  and  shot  or  verified  to 
be  out  of  commission.  Either  case  helped 
the  Tomahawk  Strike  Coordinator  plan  for 
future  operations.” 

NUWC  continues  to  provide  the 
operational  Fleet  with  tremendous  support 
and  capability.  The  efforts  in  providing 
chat  capability  are  yet  another  example  of 
the  teamwork  evident  across  NUWC  and  I 
am  proud  of  these  accomplishments.  Since 
the  first  phone  call  in  October  01  the  team 
has  provided  outstanding  support  to  the 
Fleet,  giving  them  the  confidence  to  carry 
out  their  mission — and  it's  only  a  SIPRnet 
chat  away. 


Donald  McCormack , 
Acting  Executive  Director 


NUWSCOPE 
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APPENDIX  E.  NAVY-MARINE  CORPS  UNCLASSIFIED 
TRUSTED  NETWORK  PROTECTION  POLICY 


1 .  The  Navy-Marine  Corps  Unclassified  Trusted  Network  Protection 
(UTNProtect)  Policy  1  is  the  guidance  for  interconnection  between  Navy  and  Marine 
Corps  trusted  networks  (complies  with  this  policy)  and  untrusted  networks  (NIPRNET). 
The  basic  policy  is  one  of  “deny  by  exception”  for  firewall  access. 

2.  Section  4  of  the  UTNProtect  Policy  was  downgraded  to  unclassified. 2  This 
section  lists  the  current  ports  that  are  open  to  inbound/outbound  internet  traffic  to 
untrusted  networks. 

3.  Traffic  between  trusted  networks  is  allowed.  A  request  at  each  end  should  be 
made  to  the  respective  firewall  administrator  to  open  a  specified  port  for  use. 

4.  Currently,  at  NPS,  port  443  (SSL)  is  open  for  use.  However,  the  firewall 
administrator  should  be  contacted  prior  to  use  to  ensure  adequate  capabilities  are 
available. 

5.  Requests  for  specific  ports  to  be  opened  with  accompanying  justification  are  to 
be  submitted  to  NCO  (N6142)  and  SPAWAR  PMW161  via  message  traffic.  Further 
guidance  is  found  in  UNTProtect  Policy. 3 


1  CNO  N614/HQMC  C4,  did  310ct2002. 

2  CNO  ltr  5239  Ser  N614/3U605717  did  30May2003. 

2  https://infosec.navy.mil/pub/docs/documents/navyn/utn/Navy_Marine_Corps 
UTNProtect_Policy_(FOUO)_3 10ct2002.doc. 
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APPENDIX  F.  TASK  FORCE  WEB  SECURITY  REQUIREMENTS 


The  following  security  requirements  come  from  Task  Force  Webs’  Application 
Development  Guide,  Appendix  G:  Application  Security,  Version  1.12,  February  10,  2003. 

There  are  two  important  interfaces  that  must  be  secured  when  migrating 
applications  and  content  into  the  Navy  Enterprise  Portal  (NEP):  the  portlet  interface  and 
the  user-facing  service  (UFS)  interface  to  the  portal.  It  is  the  responsibility  of  the  NEP  to 
secure  the  portlet  interface.  It  is  the  responsibility  of  the  application  owner  to  secure  the 
UFS  interface,  with  the  assistance  of  the  services  provided  by  the  NEP.  Furthermore,  the 
application  owner  must  address  application-specific  security  measures  for  the  UFS  (and 
the  hardware  supporting  it)  to  meet  the  requirements  of  the  application’s  developmental 
DAA. 


Figure  88.  Scope  of  application  security  for  Task  Force  Web.  Adapted  from  [From 

TFWeb  2003]. 


The  most  significant  decision  made  by  the  application  owner  is  whether  the 
security  used  by  the  UFS  interface  to  the  portal  provides  an  adequate  level  of  trust  for  the 
data  accessed  through  the  UFS.  If  the  owner  chooses  to  not  trust  these  mechanisms,  he 
may  choose  to  require  a  separate  authentication  to  the  application.  If  the  application  re- 
authenticates  portal  users,  it  must  do  so  in  a  portal-friendly  manner  (such  as  not 
automatically  popping  up  new  windows). 
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1.  Portlet  Interface  Security  Description  -  Current  Architecture 

Note  that  the  NEP  does  not  support  all  certificates  issued  by  DoD  certificate 
authorities  (CAs).  Currently,  only  certificates  in  the  hierarchy  based  on  the  DoD  Class  3 
Root  CA  certificate  are  supported  (this  includes  DoD  Class  3  CA-3,  DoD  Class  3  CA-4, 
and  DoD  Class  3  CAC  CA.)  Certificates  in  the  hierarchy  based  on  the  DoD  PKI  Med 
Root  CA  are  not  supported  (this  includes  Med  CA-1  and  Med  CA-2.) 

The  portal  perfonns  a  two-factor  authentication: 

The  portal  client  is  asked  to  present  a  login  and  password. 

•  Encrypted  connection  -  the  portal  can  interface  with  the  application  using  an 
encrypted  connection.  Currently,  the  NEP  can  only  support  SSL  connections 
over  the  UFS  interface.  Other  encryption  standards  such  as  TLS  are  not 
supported. 

•  The  certificates  are  checked  against  the  appropriate  DoD  root  trust  chain  and 
certificate  revocation  list  to  ensure  validity. 

•  The  user  enters  his  or  her  common  identity  UserlD  and  password. 

•  The  UserlD  is  authenticated  against  the  Naval  Global  Directory  Service 
(NGDS)  and  user  roles  are  passed  to  the  portal.  User  roles  detennine  which 
library  of  services  is  made  available  to  the  user. 

After  authentication,  the  portal  can  then  provide  the  common  identity  UserlD  to 
any  portal  service  via  HTTP  or  HTTPS  by  the  portal  request  interface  (PRI)  Request  or 
by  authorization  HTTP  header  field. 

2.  Portlet  Interface  Security  Description  -  Objective  Architecture 

A  COTS  single-sign-on  (SSO)  product  is  the  next  step  in  accessing  security 
implementation  for  services  integrated  into  the  NEP.  Presently,  a  product  has  not  been 
implemented  for  use.  Guidance  for  the  implementation  of  the  SSO  product  will  be 
provided  in  the  future.  Contact  the  AMCS  for  further  information. 
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3. 


User-Facing  Services  (UFS)  Interface  Security  Implementation 

The  NEP  can  provide  two  items  for  applications  and  services  via  the  UFS 
interface: 

•  Encrypted  connection.  The  portal  can  interface  to  the  application  using  an 
encrypted  connection.  Currently,  NEP  policy  states  that  the  portal  shall  only 
support  SSL  connections  to  UFS  or  DOS. 

•  Common  identity.  The  portal  sends  the  common  identity  through  the  PRI 
request  and/or  authorization  header  field  (recommended)  in  the  HTTP  header. 

The  multiple  combinations  of  the  above  items  are  listed  in  Figure  88. 


Common  Identity  Sent 

Encrypted  Connection 
(SSL) 

No 

No 

Yes 

No 

No 

Yes 

Yes 

Yes 

Figure  89.  Security  implementation  combinations  for  user-facing  services.  [From 

TFWeb  2003] 

The  following  examples  use  different  combinations  of  portal  capabilities  to  secure 
the  UFS  interface.  These  examples  are  not  all-inclusive.  Each  has  advantages  and 
disadvantages  and  different  trust  levels.  An  example  using  the  future  SSO  product  is  also 
included.  The  decision  on  which  combination  to  use  is  based  on  information  needed 
within  the  application/service.  Section  V  of  Web  Site  Administration  Policies  & 
Procedures,  contains  examples  and  best  practices  for  Web  information  security.  [Policies 
1998] 

4.  Example  1:  A  General  Public  Service 

The  portal  provides  no  common-identity  information  or  PRI  request  header,  nor  is 
the  UFS  interface  encrypted.  Examples:  Early  Bird  News  Service,  National  Weather 
Service  information. 
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Advantages 

Disadvantages 

Higher  Performance 

Higher  risks,  since  host  server  is  exposed 
to  the  general  Internet  population;  however 
equal  to  current  risk  assumed. 

No  application  userlD/password 
infrastructure  required 

Should  not  be  used  for  applications 
requiring  any  form  of 
authentication/authorization. 

Easy  to  implement 

Requires  periodic  synchronization 

Figure  90.  Advantages  and  Disadvantages  of  using  a  General  Public  Service  to  secure 

a  UFS  interface.  [From  TFWeb  2003] 


Users  of  a  service  using  this  security  methodology  are  considered  to  be 
anonymous,  because  they  cannot  be  authenticated  over  the  unencrypted  UFS  interface. 
Data  passed  over  the  UFS  interface  will  also  be  in  the  clear.  This  methodology  provides 
no  trust. 


5.  Example  2:  An  SSL  Service 

The  portal  provides  no  common  identity  information  or  PRI  request  header,  but 
the  UFS  interface  is  encrypted. 

Note:  Applications  and  services  that  are  designed  to  be  inaccessible  by  the  general 
public  must  obtain  a  DoD  server  certificate  and  use  two-way  SSL  per  CNO  message 
DTG  301704Z  NOV  00.  Example:  https://www.infosec.navy.mil 


Advantages 

Disadvantages 

Most  browsers  support  SSL. 

Requires  a  DoD  PKI  server  certificate. 

Existing  means  of  application 
authentication  can  still  be  used. 

Lower  perfonnance. 

Figure  91.  Advantages  and  Disadvantages  of  using  a  SSL  to  secure  a  UFS  interface. 


[From  TFWeb  2003] 


To  provide  assurance  of  the  user’s  identity,  the  service  must  re-authenticate  the 
user  independently  of  the  portal,  in  a  portal-friendly  manner.  Data  sent  over  the  UFS 
interface  will  also  be  encrypted,  assuring  that  it  will  not  be  compromised  in  transit.  With 
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user  re-authentication,  this  methodology  provides  a  high  level  of  trust.  Without 
authentication,  this  methodology  provides  no  trust  of  user  identity,  but  a  high  level  of 
trust  for  data. 


6.  Example  3:  Portal-supplied  Common  Identity  Without  SSL 

The  portal  provides  common  identity  information;  however,  the  UFS  interface  is 
not  encrypted. 

Note  that  the  application/service  can  use  the  common  identity  as  a  means  of 
identifying  users  and  possibly  tailoring  its  functionality  based  on  common  identity.  For 
example,  an  application  or  service  receives  a  common  identity  for  tracking  information 
such  as  date  of  last  login.  Implementing  the  common  identity  on  existing  applications 
requires  a  mapping  from  the  common  identity  to  existing  application  userlD. 
Authentication  and  authorization  of  application  rights  without  SSL  is  prohibited  by 
current  policy. 


Advantages 

Disadvantages: 

Common  identity  is  available  to  provide 
personalization  of  the  service. 

The  existing  applications  will  need 
modifications  to  support  the  common 
identity  (Mapping). 

Higher  performance  without  SSL. 

Must  read  header  field  or  parse  PRI  to 
determine  common  identity. 

Should  not  be  used  for  applications 
requiring  any  form  of 
authentication/authorization. 

Figure  92.  Advantages  and  disadvantages  of  using  a  portal-supplied  common  identity 
without  SSL  to  secure  a  UFS  interface.  [From  TFWeb  2003] 


Users  of  a  service  employing  this  security  methodology  are  considered  to  be 
anonymous,  because  they  cannot  be  authenticated  over  the  unencrypted  UFS  interface. 
However,  if  the  application  owner  and  the  DAA  accept  the  risk,  the  common  identity 
could  be  used  for  personalization.  Data  passed  over  the  UFS  interface  will  also  be  in  the 
clear.  This  methodology  provides  a  very  low  level  of  trust. 
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7.  Example  4:  Portal-supplied  Common  Identity  with  SSL 

The  portal  provides  common  identity  information  and  the  UFS  interface  is 
encrypted.  The  application/service  uses  the  common  identity  as  a  means  of  identifying 
users,  tailoring  its  functionality,  and  possibly  assigning  application-local  roles  to  those 
users.  A  use  of  this  combination  would  be  to  mimic  an  SSO  capability.  An 
application/service  may  choose  to  accept  the  passed  common  identity  to  allow  access  and 


perform  authorization  for  that  user. 


Advantages 

Disadvantages 

Support  for  the  user’s  identity  is  now 
shifted  away  from  the  application/service 
developer.  The  application  owner  no  longer 
needs  to  manage  user  passwords,  but  must 
still  manage  users  for  means  of 
authorization. 

The  existing  applications  will  need 
modifications  to  support  the  common 
identity.  Application  local  user  information 
will  need  to  be  stored  in  a  local  database. 

Common  identity  may  be  used  for  re¬ 
authentication  to  the  application/service, 
because  passwords  are  sent  encrypted. 

Requires  a  DoD  server  certificate. 

Can  eliminate  multiple  login  screens. 

Lower  performance. 

Figure  93.  Advantages  and  disadvantages  of  using  a  portal-supplied  common  identity 

with  SSL  to  secure  a  UFS  interface.  [From  TFWeb  2003] 


The  service  may  choose  to  use  the  common  identity  (without  password)  as  its 
authentication  or  may  require  the  user  to  re-authenticate  to  an  internal  user  database  or 
the  NGDS  common-identity  store.  Data  sent  over  the  UFS  interface  will  also  be 
encrypted,  providing  assurance  that  it  will  not  be  compromised  in  transit.  Using  the 
common  identity  (without  password)  as  user  authentication,  this  methodology  provides  a 
moderate  level  of  trust.  With  user  re-authentication  (against  internal  store  or  NGDS),  this 
methodology  provides  high  trust. 


8,  Example  5:  Portal-supplied  Common  Identity  with  COTS  Single  Sign  on 
(SSO)  Product  and  SSL 

The  portal  provides  common-identity  information,  and  the  UFS  interface  is 
encrypted.  The  service  uses  the  common  identity  as  its  authentication,  through  the  SSO 
product.  Data  sent  over  the  UFS  interface  will  also  be  encrypted,  providing  trust  that  it 

will  not  be  compromised  in  transit.  This  methodology  provides  high  trust. 
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Advantages 

Disadvantages 

Support  for  the  user  identity  is  now  shifted 
away  from  the  application/service 
developer.  The  application  owner  no  longer 
needs  to  manage  user  passwords,  but  must 
still  manage  users  for  means  of 
authorization. 

Existing  applications  have  to  map  the 
common  identity  to  the  existing  user 
names.  Application  local  user  information 
will  need  to  be  stored  in  a  local  database. 

Passwords  are  never  sent  over  the  UFS 
interface. 

Requires  a  DoD  server  certificate. 

Uses  the  portal  login  for  application 
authentication.  Eliminates  multiple  login 
screens. 

Lower  perfonnance. 

Figure  94.  Advantages  and  Disadvantages  of  using  a  Portal-supplied  common 
identity  with  COTS  Single  Sign  On  (SSO)  product  and  SSL  to  secure  a  UFS 
interface.  [From  TFWeb  2003] 


The  service  uses  the  common  identity  as  its  authentication,  through  the  SSO 
product.  Data  sent  over  the  UFS  interface  will  also  be  encrypted,  providing  trust  that  it 
will  not  be  compromised  in  transit.  This  methodology  provides  a  high  level  of  trust. 
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